[unixODBC-dev] SQLSetConnectAttr/SQLGetConnectAttr attribute values
Jack.Schueler at sybase.com
Jack.Schueler at sybase.com
Tue May 11 18:39:04 BST 2010
I ran into the following 32-bit/64-bit ODBC issue.
The current Microsoft spec for SQLSetConnectAttr/SQLGetConnectAttr
describes the numeric attribute values as SQLUINTEGER. This is at
variance with the SQLSetStmtAttr/SQLGetStmtAttr attribute values which are
described as SQLULEN.
There is one connection attribute, SQL_ATTR_ODBC_CURSORS, that is handled
by the Microsoft ODBC Driver Manager. The ODBC spec says the following.
------------------
SQL_ATTR_ODBC_CURSORS (ODBC 2.0)
An SQLUINTEGER value specifying how the Driver Manager uses the ODBC
cursor library:
SQL_CUR_USE_IF_NEEDED = The Driver Manager uses the ODBC cursor library
only if it is needed. If the driver supports the SQL_FETCH_PRIOR option in
SQLFetchScroll, the Driver Manager uses the scrolling capabilities of the
driver. Otherwise, it uses the ODBC cursor library.
SQL_CUR_USE_ODBC = The Driver Manager uses the ODBC cursor library.
SQL_CUR_USE_DRIVER = The Driver Manager uses the scrolling capabilities of
the driver. This is the default setting.
------------------
Despite what the spec says, here is the observed behavior in a 64-bit test
application that I wrote.
The SQLGetConnectAttr call is handled in the driver manager. Notice the
before and after value. This is NOT treated as SQLUINTEGER.
0x1234567812345678 unsigned __int64
rc = SQLGetConnectAttr( hdbc, attr, &datavalue, 0, 0 );
0x0000000000000002 unsigned __int64
I checked out the behaviour of the Microsoft SQL Server ODBC driver,
wondering if the spec was in error. For all other connection attributes,
Microsoft's ODBC driver returns SQLUINTEGER (the same behavior as the SQL
Anywhere ODBC driver).
I would rule the SQL_ATTR_ODBC_CURSORS behavior as a Microsoft Driver
Manager bug.
A question for the unixODBC folks. How do you handle the numeric
attribute values for SQLSetConnectAttr/SQLGetConnectAttr - SQLUINTEGER or
SQLULEN?
Jack Schueler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-dev/attachments/20100511/28236dd0/attachment.html>
More information about the unixODBC-dev
mailing list