Ok new thread now that I've had some time to digest.

On Thu, Oct 15, 2015 at 3:24 PM John Yeung <gallium.arsenide@xxxxxxxxx>

- Go through a STRPDM tutorial for SQL just to get familar with the
- Do the next DB schema design project with SEU and RUNSQLSTM

Not sure how PDM relates to SQL, or how SEU relates to RUNSQLSTM; but
yeah, I guess if you're just exploring and you don't know a lick of
RPG or CL then sure, knock yourself out.

The particular RPG programmer I deal with at the moment stores DDL SQL in
source members in a source file called QSQLSRC. The file has the same name
as the table. He edits the file with SEU and executes with RUNSQLSTMT. I
assumed this was a common practice, especially since QSYS2.GENERATE_SQL
lets you create the source member after the fact. So am I just learning a
pattern that this particular client uses, or am I learning a pattern that
I'll find elsewhere as I deal with different RPG programmers from different

Second question, this particular RPG programmer uses TXT source members to
store SQL. Would SQLC or some other format be better? I can't find the
developer works page that tells me what all the source member types are

Thirdly, I've been trying to generate source members like this:


I do that in SQL Workbench, and if I mess up a parameter, like specify a
table that doesn't exist, I don't get a useful error message. The helpful
error message is in the the joblog, that I get with SELECT * FROM
table(QSYS2.JOBLOG_INFO('*')) a; Is there a way to get the ORDINAL_POSITION
or MESSAGE_ID of a failed sql statement so I can look up the message that
way? All I get back now is "[SQL0443] QSQGNDDL ERROR [SQL State=58004, DB
Errorcode=-443]". I guess I could get the timestamp as a variable before I
send the statement and then put that in the WHERE clause.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].