Re: SQLCA elements not working in internal procedure

Thanks to all for the replies.  It's working now.

Here's what I think *may* have happened.  The program contains two modules, one RPGLE and one CLLE.  The overall purpose of the program is to find what will prove to be the last journal entry that will be processed by a Data Mirror subscription, once the subscription catches up to a defined point (the DM subs can lag behind).

The RPGLE module currently in use doesn't have a sub-procedure. I'm modifying it to add one.  I compiled the module and then updated the copy of the program that Aldon LMi put into my developer library with UPDPGM, specifying the modified RPGLE module.  What I think may have happened is the program object somehow didn't get updated properly to make the global variables in the mainline part of the RPGLE module visible to the new sub-procedure.  That doesn't really make a lot of sense to me, but when I deleted the program altogether and created it from scratch with CRTPGM, everything began working normally.

Thanks again for the responses.

On 5/8/2019 8:07 AM, Craig Richards wrote:

Like Dave - I have got vast amounts of code in subprocedures which look at
SQLCODE and/or SQLSTATE.

You haven't somehow created a "local" version of these fields in the
subprocedure which is preventing code in your subprocedure from seeing the
global versions?

regards,
Craig

On Wed, 8 May 2019 at 15:59, <dlclark@xxxxxxxxxxxxxxxx> wrote:

"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> wrote on 05/07/2019
06:57:37 PM:

I have a SQLRPGLE program with SQL in both the mainline and an internal
(not exported) procedure. When I check SQLSTATE in the mainline, the

value

reflects the result of the last SQL operation. In the procedure, it is

not

being updated. None of the SQLCA elements are updated for SQL in the
procedure.

Is there a hidden trick to make the SQLCA elements work in a procedure?

No special requirements of which I am aware -- except that the
table data structure on which the SQL is based should be defined in main
global storage. We have many, many SQL programs that perform SQL
statements in subprocedures and check SQL STATE with no problems. We even
have some that open a cursor in one subprocedure, fetch from that same
cursor in another subprocedure, and close that same cursor from yet
another subprocedure. All can check SQLSTATE with no problems.

Sincerely,

Dave Clark
--
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331





*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.

*********************************************************************************************
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com