home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Neueste VersionenFixList
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Haben Sie Probleme? - Kontaktieren Sie uns.
Kostenlos registrieren anmeldung-x26
Kontaktformular kontakt-x26

DB2 - Problembeschreibung

Problem IC86035 Status: Geschlossen

INTERMITTENT -435 WHEN SIGNALLING SQLSTATE IN A SQL ROUTINE

Produkt:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problembeschreibung:
A SQL routine may fail with the following error intermittently: 
 
SQL0435N  An invalid application defined SQLSTATE "<sqlstate>" 
was specified. 
 
This would happen if there was a SIGNAL or RESIGNAL statement 
where the SQLSTATE value was being supplied to a variable.   The 
issue happens because a random junk byte (in the range 0-9,A-Z) 
gets stored after the SQLSTATE variable causing us to believe 
the length of the SQLSTATE variable is longer than expected.  If 
the length is more than 5 bytes it would violate the rules for 
an SQLSTATE in a SIGNAL/RESIGNAL statement and thus return an 
SQL0435N error at run-time.
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* ALL                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 9.7, Fixpak 8                         * 
****************************************************************
Local-Fix:
Instead of using a CHAR(5) value for the SQLSTATE variable, 
create a new type outside of the routine that has two elements 
(a CHAR(5) value to use for the SQLSTATE variable, and a CHAR(1) 
value to use as a fence character) like this: 
 
CREATE TYPE state_holder AS ROW (state CHAR(5), fence CHAR(1)); 
 
Then inside the routine declare a new variable by using that new 
type that was created.  We then give the STATE field a copy of 
the SQLSTATE output variable and we give the FENCE field an 
invalid SQLSTATE character (ie, outside the range 0-9,A-Z) as 
follows: 
 
BEGIN 
             DECLARE HOLDER state_holder; 
             DECLARE SQLSTATE_OUT CHAR(5); 
 
             ... 
 
             -- Before the signal, copy SQLSTATE_OUT to the 
holder, and fence it off 
             -- with a known invalid SQLSTATE character: 
             set holder = (SQLSTATE_OUT, '#'); 
             SIGNAL SQLSTATE holder.state SET MESSAGE_TEXT = 
...; 
 
 
With the SQLSTATE output variable now fenced off with an invalid 
character, DB2 will only read up to the 5 characters for the 
SQLSTATE and not fail if the 6th character was also a valid 
character, thus having DB2 think the total size of the SQLSTATE 
is larger than it should be.
verfügbare FixPacks:
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows

Lösung
First fixed in DB2 Version 9.7, Fixpak 8
Workaround
see Local Fix.
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
21.08.2012
15.04.2013
15.04.2013
Problem behoben ab folgender Versionen (IBM BugInfos)
9.7.
Problem behoben lt. FixList in der Version
9.7.0.8 FixList