[unixODBC-dev] SQLSetConnectAttr/SQLGetConnectAttr attribute values
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
> 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
For better or worst, unixODBC 2.3.0 treats the attribute in question as
More information about the unixODBC-dev