DB2 FOR LUW / DB2FORLUW / 970 - DB2

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.

**************************************************************** 
* USERS AFFECTED:                                              * 
* Users of applications that use the CLI (Call Level           * 
* Interface) API with DB2 for Linux, UNIX and Windows          * 
**************************************************************** 
* 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.                                 * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* .                                                            * 
****************************************************************

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.

DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
 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
 

Problem was first fixed in Version 9.7 Fix Pack 5. 
At a minimum, this fix should be applied on the client.

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.

Vorgänger  : APAR is sysrouted TO one or more of the following: IC73576 IC73577 
Nachfolger : 

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

15.12.2010
23.12.2011
23.12.2011

9.7.FP5