RE: RPG/LE SQL Result Sets - A real Challenge

["Carel Teijgeler" <coteijgeler@xxxxxxxxx>]

Arturo, 

Some loose comments from me.
The result sets should be parsed per record to be converted into XML.

The best ooption is to have one SQL statement with many LEFT OUTER  JOINS and 
somewhere in the process you have to deal with the null values returned.

The resulting XML document should comply to the XML scheme it is based on. This 
means that at level two in your example level three can 0 to many occurences. 
the result set will return as many records that are in level three, but level 
two may only appear once in the XML documnet at that point.

More questions, too:
How are you going to aproach the AS/400 as server (ODBC, JDBC, other)?
Where are you intend to build the XML document (output to the IFS and pick it 
up from there)? 

The setup you have given now is rather vague (and with five result sets I fear 
for performance).

Regards,
Carel Teijgeler
*********** REPLY SEPARATOR  ***********

On 27-3-03 at 9:24 Arturo_Duarte@xxxxxxxxxxxxxxx wrote:

>Business Goal:
>To retrieve a number of records from different database sources, that are 
>loosely connected by a single key (account number), format the data to a 
>usable content/context and return all the data to a Web based XML powered 
>application.
>
>As outlined:
>The use/requirement for a "result set" is the method I am most familiar 
>with.  Other options are certainly possible.  My limited knowledge in 
>communicating with Web based intra/inter- net applications is in turn, 
>based on SQL, either in native form inside a stored procedure, or in 
>native form inside an RPG/LE program, which is called/executed by a 
>defined stored procedure.  My other team member is more client/server 
>based in his knowledge.  His knowledge is somewhat limited in the 
>acquisition/use of AS/400 based data.  He is constructing the front end of 
>the application, I've been charged with constructing the back-end (data 
>I/O).  I have constructed the RPG/LE code to read required data from all 
>five tables and capture the data read.  What I lack is the knowledge of 
>how to provide that data back to the front-end.  Up until this point, I 
>thought it would be via imbedded SQL, with a "result set" returned.