[unixODBC-dev] SQLSetConnectAttr/SQLGetConnectAttr attribute values

Nick Gorham nick at lurcher.org
Tue May 11 20:16:43 BST 2010

Jack.Schueler at sybase.com wrote:
> 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 
> Jack Schueler

For better or worst, unixODBC 2.3.0 treats the attribute in question as 


More information about the unixODBC-dev mailing list