RE: SQLSTATE 01004 now appears with v7.1 ?

Michael,

I hope you are in the position to make changes like this as Rory is saying....it is the best way to go .... but if you are like me as a consultant ... companies are stuck on the least changes by a day .... instead of best way in the same time..or less.... even when something like this is QA'd to the SOX level. Or better....

Hope you can... it will help to promote....





-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Rory Hewitt
Sent: Monday, October 24, 2011 6:27 PM
To: RPG programming on the IBM i / System i
Subject: Re: SQLSTATE 01004 now appears with v7.1 ?

Michael,

You say that you have many instances in your code of this check (for a
substring of SQLSTATE).

Have you considered putting the required code into a procedure in a service
program module (and/or ina callable program, if some of these are OPM
programs)? Something like this:

for x = 1 to 10;
exec sql
fetch next
from EPstatusCursor
into :Type;

* if checkSqlState(SQLSTATE) = Success;*
// SQL executed successfully
EquipmentTypes(x) = Type;
else;
NextElement = x;
LEAVE;
endif;
endfor;

That way, there is only one place where these checks need to be made - in
the checkSqlState() procedure. You can also choose to return different
values (Error, Warning, Success), which you can process in your in-line code
as you wish. Finally, this also gives you one place to invoke any auditing
or logging functionality you might want to put in there (such as writing to
a spooled file or database file if an error occurs.

FWIW, I wrote a procedure like this and you can have the code if you want
(once I dig it out, that is!)...

Just sayin'

Rory