On 9/6/2011 4:04 PM, Morgan, Paul wrote:
Why isn't it suited? RPG throws errors on file level checks when the
table format changes. It can't do the same for a missing or changed
column? Don't you get warning or hard errors with embedded SQL?
RPG already has three native ways of handling file i/o (not counting
SQL) It has Input/Output specs, externally defined files, and data
structure I/O.
All of them are based on physical positions within a record. RPG
requests an entire record from the database, and then splits that record
into fields using from/to positions.
With externally defined files, the input/output specs are automatically
generated at compile time -- but they still exist.
Data structure I/O bypasses input/output specs, but it reads a raw
record buffer (whole record at once) into the data structure. It does
not go through the record field-by-field.
What you are suggesting would require RPG to go through the record one
field at a time, determine the data type of the fields, and convert from
the file's field type/size to the program's file type/size.
Would that work? Sure. But it means RPG has to read the database by
the field rather than by the record. To implement it would almost
certainly require a fourth method of handling files with native i/o.
Currently new RPG programmers need to learn program-described I/O specs,
traditional externally defined files, and data structure I/O. You are
asking for a fourth method that they'd have to learn, that's field-based
rather than record-based. I think that's where the "frankenstein"
comment comes from -- over the years, it keeps having more functionality
added on, so programmers need to learn lots of ways of doing everything...
It certainly can be done, but is it worth it? Is it really that hard
to recompile a program? Or, if you truly don't want to, why not use
embedded SQL that already does what you want?
Catching type errors as soon as possible is the point. At compile
time instead of run time is better if you can do it. That can be
done with a static typed code variable linked to a static database
column type.
I'm not sure I follow how something like this would catch type errors
earlier? Surely you already catch the type errors when you compile?
I'm not really wishing for dynamic typing in RPG. I want dynamic
data conversion between a current database column type (checked at
compile time and rechecked at run time) to a static code variable
type (set at compile time).
(This is the bit my response, at the top of this message, was responding
to.)
Isn't embedded SQL a better Frankenstein analogy? Two different
languages stitched together.
Perhaps, but every language out there uses SQL for database access. C,
VB, Java, C#, PHP, you name it... and embedded SQL is easier to code
and debug (not to mention more efficient) than using an API-based
approach like ODBC/CLI or JDBC. So I think embedded SQL compares
favorably to the alternative languages.
midrange.com
