hi Nathan,
The difference between using SQL with a program-defined data structure
and your suggestion of using an externally-defined DS with a
program-described read is rather important, I think.
With SQL, it reads the data one field at a time, and copies it to the
RPG field. IF the database definition is changed, an attempt is made to
convert the field from the database style to the program's definition.
For example, if the field has been enlarged from 9 digits to 11 digits,
the SQL would do the equivalent of an "eval", converting the field to
the 9-digit size because that's what the program has.
If the SQL technique uses an ext-def DS, then when the program is
recompiled, it'll automatically adjust the field to the new size. But
in the mean-time it did the best it could -- it converted the field back
to the original size on-the-fly
Compare that to your program-described READ technique with the ext-def
DS. In your case, if the field size changed from 9 to 11, it won't be
detected (unless the total record size has also changed, in which case
you'll get an error.) So if the field size got larger, but the record
size is the same (due to changes in other fields) your technique will
result in part of the DB field being loaded in to one program variable,
and another part being loaded into an unrelated variable. Try it!
If the record size changed, then you'll get an error when reading -- and
therefore will be in the same exact situation you were with
LVLCHK(*YES)... no benefit from using your technique in that case.
And the difference between using a DS for a keylist and using an actual
keylist is that RPG knows it's a keylist. In your case with the DS, the
raw bytes of the combined fields are used as a key... which works in
most cases, I guess.
But there are cases where there's additional functionality available
when RPG knows about each key in a composite keylist separately gfrom
the others. For example, you can READE on a partial key with an
externally-defined F-spec, just by specifying the first key in the
keylist. You can't do that in a program described scenario, you always
have to specify the entire keylist. Also, what happens if a key is
defined where part of the key is ASCEND and part is DESCEND? Or
something like absolute value on a key?
Plus, if your goal is simply to turn off level checking... why not just
specify LVLCHK(*NO)? Wouldn't that make it easier for the next guy to
see what you're up to?
On 11/7/2012 1:18 PM, Nathan Andelin wrote:
This essentially does the same thing as LVLCHK(*NO) -- it's just an
alternate way of throwing away all of your safeguards.
No, throwing off all your safeguards would be using internally defined data structures or "i" specs to define file layouts. Nobody is suggesting going back to that. There have been several discussions recently about mapping sql "select" and "fetch" operations into MODS, DS arrays, internally and externally defined data structures, variables. All those ideas seem to be promoted with impunity.
What if you use sql select xyz into :var, then someone changes the data type for "xyz"? How much of a safety net do we need? With this RLA technique, I already discovered that if the length of the data structure in the "d" spec gets out of sync with the length in the "f" spec, the compiler will generate an error.
this technique also throws away the ability to use proper keylists
What really is so meaningful about a keylist vs. a data-structure key with sub-fields?
-Nathan.
midrange.com
