Before I would make wholesale changes to my code on the presumption that
SQLCODE is not functioning correctly within that code body, I would create
the simplest example, independent of the code that is erroring, compile that
and see if you can get it to error in the same manner.
If SQLCODE does not function correctly, then you have a basis for a
submission to RBTI, but failing that, then you have to expand your example
to more closely replicate where it is failing in your code body until you
get the SQLCODE error that doesn't square with your expectation.
At that point you would look at some of the issues that Emmitt suggested,
like triggers that could change the SQLCODE prior to your checkpoint.
----- Original Message -----
From: "MDRD" <[email protected]>
To: "RBASE-L Mailing List" <[email protected]>
Sent: Friday, May 14, 2010 9:47 AM
Subject: [RBASE-L] - Re: Scratch
Thanks Tom and Paul
Good to know I am still using the 3/5/10 version .... I hope I am OK for now
and I can take time to ck and improve my code.
Thanks
Marc
From: TOM HART
Sent: Friday, May 14, 2010 8:16 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Scratch
It started happening on the March 31 build, which is the last one.
Tom Hart
--------------------------------------------------------------------------------
From: MDRD <[email protected]>
To: RBASE-L Mailing List <[email protected]>
Sent: Fri, May 14, 2010 7:11:26 AM
Subject: [RBASE-L] - Re: Scratch
Do you know which version of the Compiler this changes?
Thanks
Marc
From: TOM HART
Sent: Thursday, May 13, 2010 6:18 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Scratch
It appears that the sqlcode is not reliable on the new compiler 7.6 update.
I changed the code the err var and it worked. Now I need to go thru and
change all my codel
Tom Hart
--------------------------------------------------------------------------------
From: "[email protected]" <[email protected]>
To: RBASE-L Mailing List <[email protected]>
Sent: Thu, May 13, 2010 9:23:31 AM
Subject: [RBASE-L] - Re: Scratch
Tom: I can't tell you why I made this decision, but there is only
one place in all my program code all over this country going back to
2.11 days where I use the SQLCODE command. The only place I
use sqlcode is within a cursor:
fetch c1 into vproductid
if sqlcode = 100 then
break
endif
I never use sqlcode anywhere else for testing. I guess I didn't
trust that the same command would "break" a sqlcode reliably
from version to version.... But as I said, personal choice and I
can't comment on whether it's a good idea to use sqlcode or not...
Karen
First off I want to thank Razz, Rachael, and Albert for their help. I did
get it to work right. Now I have a question, what happened from the last 2
compiler builds. This code I posted I have been using for at least 2 years,
at 3 locations, and on more than 10 computers and have never once had this
happen. Is it better to use the code you posted and/or is the sqlcode
becoming obsolete. I am sure I have sqlcode elsewhere in my app, but
obviously employees clock in and out everyday, so it came up first. I have
not changed the code or form at all, just re-compiled my startup file with
the newer compiler version.
Tom Hart
