home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Latest versionsfixlist
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
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IC73577 Status: Closed

SQLEXECUTE OF "UPDATE ... WHERE CURRENT OF CURSOR-NAME" MIGHT
INCORRECTLY FAIL WITH ERROR SQL0519

product:
DB2 FOR LUW / DB2FORLUW / 950 - DB2
Problem description:
SQLExecute might incorrectly fail (return SQL_ERROR) when you 
pass it the statement handle for an 
"UPDATE ... WHERE CURRENT OF <cursor-name>" statement. If you 
then call SQLGetDiagRec it reports error SQL0519N. 
 
The problem happens if the "SELECT ... FOR UPDATE" statement 
associated with the cursor <cursor-name> 
has one isolation level and the "UPDATE .. WHERE CURRENT OF 
<cursor-name>" statement has a different isolation level set by 
using the SQL_ATTR_STMTTXN_ISOLATION or SQL_ATTR_TXN_ISOLATION 
statement handle attributes.
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* Users of applications that use the CLI (Call Level           * 
* Interface) API with DB2 for Linux, UNIX and Windows          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* .                                                            * 
****************************************************************
Local Fix:
As a workaround, rather than setting the isolation level for 
individual statements set the isolation level for the 
connection instead. You can set the isolation level for the 
connection by setting the TXNISOLATION DB2 CLI/ODBC 
configuration keyword or by setting the SQL_ATTR_TXN_ISOLATION 
attribute for the connection handle.
available fix packs:
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows

Solution
Problem was first fixed in Version 9.5 Fix Pack 8. 
At a minimum, this fix should be applied on the client.
Workaround
As a workaround, rather than setting the isolation level for 
 
individual statements set the isolation level for the connection 
instead. You can set the isolation level for the connection by 
setting the TXNISOLATION DB2 CLI/ODBC configuration keyword or 
by setting the SQL_ATTR_TXN_ISOLATION attribute for the 
connection handle.
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
29.12.2010
05.07.2011
05.07.2011
Problem solved at the following versions (IBM BugInfos)
9.5.FP8
Problem solved according to the fixlist(s) of the following version(s)
9.5.0.8 FixList