RE: RE: Populating fields based on field name in a file

rpg400-l-request@xxxxxxxxxxxx wrote:

>   8. RE: Populating fields based on field name in a file (Joe Pluta)
>
>> I strongly suggest that the original poster try the dynamic SQL before
>> throwing it out as a poor performer.  It may run pitifully slow too,
>but
>> you just don't know until you try.
>
>Nah.  CHAIN/UPDATE performs better than single-record dynamic SQL
>UPDATE.  Period.

I would normally agree with this, but can't under the circumstances. Now, if 
there's a technique using CHAIN/UPDATE that can be shown to work for what the 
original question was, and it doesn't involve so many levels of abstraction as 
to be near impossible to understand, I'd sure love to see it.

To summarize the general problem -- the field, format and file names are not 
known at compile-time. They are supplied by reading a 'File/field Definitions' 
file. Please describe what the F-spec should look like for the file and how the 
accompanying CHAIN/UPDATE statements should be coded. (That's not the precise 
problem; but I think a solution to that could be directly applied to the 
problem in this thread.)

On a related side-note...

If you're a site that doesn't have the SQL development kit, you can _still_ use 
embedded/dynamic SQL in REXX. If necessary, REXX can communicate to/from RPG 
via the REXX queue.

I put a junk REXX SQL code sample in the Midrange code repository at:

http://code.midrange.com/index.php?id=489a89e09f

That's a hastily modified REXX proc that used to do a much different task but 
now grabs and displays CustomerNumber and LastName fields from the 
QIWS/QCUSTCDT file that's probably on all of our systems. The SELECT statement 
can be built to use any file and field that SQL can read; and the FETCH 
statement can be built to match. In fact, every REXX statement can be built 
on-the-fly and executed dynamically, not just SQL statements.

Someone with spare time might take that starting point and supersede it with a 
serious attempt to make it useful -- field and file names externally supplied, 
etc., e.g. Even so, as relatively slow as it is, it still might compete with an 
RPG CHAIN/UPDATE solution that would do the same when the SQL DevKit isn't 
available.

And I'd still be interested in a good way to do it in RPG without SQL.

Tom Liotta