Hello,
Recently we switched from using plain SQL for transaction handling to the corresponding ODBC functions. Now the
applicationcrashes if 'Use Declare/Fetch' is checked in the ODBC DSN. Not everytime but when the result set does
containone row only. The course of action leading to the crash is:
1. begin transaction:
SQLSetConnectAttr(Connection, SQL_ATTR_AUTOCOMMIT, SQL_AUTOCOMMIT_OFF, SQL_IS_UINTEGER)
2. declare a cursor for a select that does yield one row/value only:
SQLAllocHandle(SQL_HANDLE_STMT, ...)
SQLSetStmtAttr(Statement, SQL_ATTR_CURSOR_TYPE, SQL_CURSOR_STATIC, SQL_IS_UINTEGER)
SQLExecDirect(Statement, "SELECT col FROM tab WHERE <primary_key = value>")
SQLDescribeCol(...)
SQLBindCol(...)
3. commit transaction:
SQLEndTran(Connection, SQL_COMMIT)
SQLSetConnectAttr(Connection, SQL_ATTR_AUTOCOMMIT, SQL_AUTOCOMMIT_ON, SQL_IS_UINTEGER)
4. move the cursor to ( or fetch ) the first result row:
SQLExtendedFetch(Statement, SQL_FETCH_FIRST, ...)
There's no crash if step 4 happens before step 3 or when using SQL commands for transaction handling.
As I understand cursors have to be declared 'with hold' to be used outside the transaction they've been declared in.
However,it seems that there's no problem if the result set does contain more than one row. This yields the first result
rowand subsequent SQLExtendedFetch(...) calls work. Alternatively using plain SQL for transaction handling works, too.
At least psqlODBC 09.03.0210 and 09.03.0300 ( both 32 bit ) seem to be affected - tested against PostgreSQL 9.2.8 64
bit( Ubuntu and Windows ).
Further tests using the psqlodbc 09.03.0300 unicode version compiled from source and MDAC 2.80 using 'ODBCTest
(Unicode,x86)' using the same ODBC function calls showed a different behavior between debug and release version. The
debugversion simply crashes and the release version returns no data if the result set contains one row only.
Best regards,
Peter
