If the data from the dataarea needs to be joined with other tables it really should not be a dataarea but a single record in a table. Then just standard SQL select and join works. If there is no need to do a join the stored procedure would be best as it can pass back the entire structure in the dataarea as separate fields all at one time.
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Elvis Budimlic
Sent: Thursday, September 04, 2008 11:02 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Reading a data area in SQL
UDF(s) will work if you need to return a single value only. Of course,
you'd need multiple UDFs to return multiple values from the data area. They
could all be part of a single service program, but multiple CREATE FUNCTIONs
would need to be run.
External Stored Procedure would work as well, as long as you're OK with the
limitation that it has to be invoked in SQL as a standalone call, i.e. CALL
dataAreaStoredProcedure(...), not part of another SQL statement (i.e. SELECT
Stored Procedure could return the values as output arguments, or as a result
set (less attractive solution in this case).
For my money, UDTF is the most elegant solution.
You can treat it as just another table (i.e. join to another, 'real' table)
and leverage it in any SQL statement (i.e. SELECT * FROM table(...) WHERE
Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
Subject: Reading a data area in SQL
does anyone know of a way to "read" a data area within SQL
My investigation, so far, has unearthed the following web page
but this entails writing a table function.
I was wondering if there was any other way.
By the way I am on V5r4
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives