Re: Create Procedure/READS SQL DATA

May have found my own answer...

The Modernizing IBM eServer iSeries Application Data Access Redbook
(SG24-6393) says:
– NO SQL DATA
The stored procedure does not contain SQL statements. This must be used for your
RPG or COBOL programs or service programs that do not contain embedded SQL.
– CONTAINS SQL DATA
This option must be used if you want to register a RPG or COBOL
program or service
program that contains SQL statements like SET, CALL, and COMMIT, but does not
access database data.
If you create an SQL stored procedure that only executes calls to other stored
procedures and set parameters, you have to specify this option, too.
– READS SQL DATA
This option must be used if you want to register a RPG or COBOL
program, where you
get access to database data by using the select statement, but no
insert, update, or
delete with SQL is performed.
If you write a SQL stored procedure that only returns result sets, you
have to specify
this option, too.
– MODIFIES SQL DATA
This option must be specified if you are inserting, updating, or
deleting data through
SQL in your stored procedure.

Granted, my usage of SQL stored procedures and UDF's pre-date the above Redbook.

One other point for those reading the thread...

If you define a procedure or UDF with READS SQL DATA, if can not call
or use another procedure/UDF defined with MODIFIES SQL DATA.

HTH,
Charles
On Mon, Jul 19, 2010 at 3:57 PM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

Good point Scott,

I was actually thinking about SQL defined procedures as opposed to
external programs.

Question: I've always treated treated RPG RLA the same as SQL for the
purposes of the "READS SQL:DATA" or "MODIFIES SQL DATA".  In other
words, if I've got an RPG program I want to call as a stored procedure
or UDF if it's only reading tables I define it with "READS SQL DATA"
but if it's updating data I define it as "MODIFIES SQL DATA".

Not sure why, I guess since I couldn't find explicit instructions it
seemed safer to say a program "MODIFIES SQL DATA" irregardless of
rather it was using SQL or RLA to do so; as I interpreted "SQL DATA"
to mean data in a table.

From your posts, it would seem that (most?) my RPG UDFs could be "NO
SQL" since they don't even use SET RESULT SETS and the stored
procedures "CONTAINS SQL".

Do you have a link to explicit instructions to that effect or is it
just a case of "it's always worked for me!" :)

Charles


On Mon, Jul 19, 2010 at 3:26 PM, Scott Klement
<midrange-l@xxxxxxxxxxxxxxxx> wrote:

Hi Charles,

In my experience, most of the stored procedures written in RPG are
actually set up as "CONTAINS SQL".  That's because they tend to be older
code that's being preserved, and called from other languages (such as
Java or PHP) via the stored procedure interface.

Since they're older RPG programs, they don't use SQL themselves, except
for the retrofitted "SET RESULT SETS" that someone added.  Since SET
RESULT SETS requires the "contains sql" level, that's what they're coded
with...

Obviously, YMMV.



On 7/19/2010 1:36 PM, Charles Wilt wrote:

Craig,

I guess that 99% of stored procedures are either READS SQL DATA or
MODIFIES SQL DATA.

However, there always that 1%.

Plus, it's not uncommon for user defined functions to be NO SQL or CONTAINS SQL.

HTH,
Charles

--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.