Since going from RLA to SELECT * FROM ONETABLE is pretty useless, I assume you are hoping to automate generating the UPDATE and INSERT statements, which are closer to record formats. Normally, I generate the work with application (they are all very much alike) and custom code the update panels from a template to get a more finished look and behavior.
If I had callers passing me stuff to update, I'd have them pass a file name, an array of name=value in text, with something similar for the keys. If speed is not important, I could just compose the statement and EXECUTE IMMEDIATE, without memory allocation, but if I was going to use a descriptor area for the update, I'd still pass the update values in an array, and stick them into the allocated memory. Data structures are so 1990's. You put pointers to the memory for each field in the descriptor area.
For me, I take a SQL SELECT of any construction (with joins, UDFs and UDTFs and CTE's) and make a green screen subfile work with list. Don't pick on me for going to green screen; I'm an old lady. I handle row selection via marker strings in the SQL that I replace with values that the user enters. Column headers are the correlation name on the select. (select mmcm# as customer, for example, shows Customer as the column header.) The application definition selects certain columns by name so it can pass them to the option processing program in an array, one entry for each column.
The result set is handled by getting the column descriptions via PREPARE, allocating appropriate memory, and then assigning pointers to the memory to the descriptor; a service program does all that, as well as formatting the various field types for the screen. But I don't write any new code (other than the SQL) just to throw up a new work with list.
I can provide code offline to allocate appropriate memory for different field types and retrieve the values by column sequence or name.
________________________________
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxx> on behalf of Nathan Andelin <nandelin@xxxxxxxxx>
Sent: Friday, October 13, 2017 10:25 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: where is SQLDATA?
Jay,
Here is a link to an article about Townsend Security licensing an ROA
handler that maps RPG RLA to SQL.
https://www.itjungle.com/2016/07/25/tfh072516-story02/
Townsend Ponders Future Of DB2 Modernization Tech - IT Jungle<
https://www.itjungle.com/2016/07/25/tfh072516-story02/>
www.itjungle.com
What will Townsend Security do with the potentially groundbreaking technology it created to solve a thorny encryption issue in DB2 for i? While the Olympia ...
I recall discussing this a little with Vern Hamberg a while back on this
list. Your ROA plans may be reinventing the wheel, so to speak, if you're
writing an ROA handler in order to facilitate FIELDPROC encoding and
decoding, per our discussion on LinkedIn.
I seem to recall Vern saying something about mapping RLA to SQL via ROA as
opening a can of worms, or getting tangled up in a mess, or something like
that.
One alternative that I've considered was using ROA to map RLA to the C
functions exported from the QC2IO service program, rather than trying to
map RLA to SQL. The handler could automate the FIELDPROC encoding for
positioning and reading by key, etc.
On Fri, Oct 13, 2017 at 1:31 PM, Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:
I'm developing a handler pgm to replicate RLA to SQL - i'm using the
namesValues method...
so my dynamic capabilities paired with the I/O ds's that rpg passes to the
handler pgm have allowed me to build the sql statement you are seeing.
I NOW, within that pgm (that is clueless to what file or field I'm banging
on), need to assign values from the row that select statement generated
into the data structures to pass back to my rpg handler pgm.
Hopefully you have a better picture of canvas now...but the question still
reverts back to my last post and question.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/rpg400-l.
RPG400-L mailing list archive (midrange.com)<
https://archive.midrange.com/rpg400-l>
archive.midrange.com
midrange.com RPG400-L mailing list archive
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
Amazon.com: Online Shopping for Electronics, Apparel, Computers, Books, DVDs & more<
http://amzn.to/2dEadiD>
amzn.to
Online shopping from the earth's biggest selection of books, magazines, music, DVDs, videos, electronics, computers, software, apparel & accessories, shoes, jewelry, tools & hardware, housewares, furniture, sporting goods, beauty & personal care, broadband & dsl, gourmet food & just about anything else.
midrange.com
