[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.
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 

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