|
Problem IC73576
|
Status: Closed |
SQLEXECUTE OF "UPDATE ... WHERE CURRENT OF CURSOR-NAME" MIGHT INCORRECTLY FAIL WITH ERROR SQL0519 |
| product: |
DB2 FOR LUW / DB2FORLUW / 910 - 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 DB2 for Linux, UNIX and Windows who run *
* applications that use CLI (Call Level Interface) *
****************************************************************
* 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: *
* . *
**************************************************************** |
| 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.1 Fix Pack 11 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 12 for Linux, UNIX and Windows
|
| Solution |
Problem was first fixed in Version 9.1 Fix Pack 11.
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 theconnection 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
14.12.2011
14.12.2011 |
| Problem solved at the following versions (IBM BugInfos) |
9.1.FP11
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.1.0.11
|
 |
