RE: SQLSTATE 01004 now appears with v7.1 ?

Brian, honestly I've never paid much attention to sqlcod, favoring sqlstate instead. I fixed today's problem by changing the length of my target field, so I don't really know if your suggestion would have worked. But thanks. Maybe I need to attend an "SQL Best Practices" class?

Chuck, the top of page 19 of the "Memo to Users - Oct 2011" you referred me to specifically mentions the situation I crashed into. Thanks. Even if I'd read that prior to our upgrade, I doubt that I would have gone through all our source looking for that possibility. Always something to keep me hoppin'!
-- Michael
~~~~~~~~~~~~~~

From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Brian Piotrowski
Sent: Monday, October 24, 2011 3:08 PM
To: RPG programming on the IBM i / System i
Subject: RE: SQLSTATE 01004 now appears with v7.1 ?

What happens if you change the %subst statement to:

if sqlcod = 0;
// SQL executed successfully
EquipmentTypes(x) = Type;
else;

? NextElement = x;

LEAVE;
endif;

/b;

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Koester, Michael
Sent: Monday, October 24, 2011 2:44 PM
To: RPG400-L@xxxxxxxxxxxx
Subject: SQLSTATE 01004 now appears with v7.1 ?

A program that has been functioning nicely for several months is now having run-time issues after our weekend upgrade from v6.1 to v7.1, and it appears to be related to my test for "if %subst(SQLSTATE : 1 : 2) = '00';" Prior to today, that test was apparently satisfied after:

fetch from [cursor] into [host variable]

even though the variable from the cursor was longer than the host variable target.

Today, the sqlstate gets a "01004" to inform me that "The value of a string was truncated when assigned to another string data type with a shorter length." So my if-test fails, and bad things happen. It's true that the lengths are not matched, but if that had shown up in my testing last March, I wouldn't be fixing production stuff today.

In the code below,
"equipment" in the EPstatus file is 16 A
and local variable "type" is 10 A

clear EquipmentTypes;

exec sql
declare EPstatusCursor cursor for
select DISTINCT equipment
from EPstatus
where order = :ServiceOrder
For Read only;

exec sql
open EPstatusCursor;

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

if %subst(SQLSTATE : 1 : 2) = '00';
// SQL executed successfully
EquipmentTypes(x) = Type;
else;
NextElement = x;
LEAVE;
endif;
endfor;

Because of SQLSTATE 01004, my EquipmentTypes array is no longer getting loaded.
Did I reach a wrong conclusion that v7.1 is handling that differently? Anyone else have similar fun with this? Are there better ways I should have coded this to prevent eventual upgrade trauma?

Got a lot of code out there that tests for "if %subst(SQLSTATE : 1 : 2) = '00';" Maybe not so much that involves cursor-variable-to-host-variable-length-mismatch, but I sure got blindsided here. Since I didn't find any references to "01004" in the archives, I thought it might help someone else, unless I've totally missed what's really causing my trouble.

Michael Koester