sizeof SQL_ATTR_TXN_ISOLATION value

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

sizeof SQL_ATTR_TXN_ISOLATION value

Chris Golledge

The Microsoft definition for the value is "A 32-bit bitmask ...".  The unixODBC driver manager implements this value as an int (SQLINTEGER).  The size of the int type is platform dependent.  On little endian systems, it works out OK for my driver to write only the first 32 bits (at least if the variable is initialized), but on a 64-bit, big endian system, like AIX (and I think Solaris), the app reading the value as a 64-bit integer when the driver has written the value into the high order bytes does not work.

There is no mention per se of this attribute at http://www.unixodbc.org/doc/ODBC64.html or http://support.microsoft.com/kb/298678, so, you might say that since it was originally a 32-bit mask, and there is no mention of it, it should remain a 32-bit mask.   But, you can get there by going around the barn. TXN_ISOLATION has been around since ODBC 1.0, at which time it was set with SQLSetConnectOption, and there is the change in the table that

    SQLSetConnectOption
    SQLULEN Value

and SQLSetConnectOption maps to SQLSetConnectAttr.

Is there a better explanation for why this attribute value becomes 64-bits on AIX?  
(Being pedantic, if this logic is correct, I'm thinking it should be declared as an SQLULEN  instead of an SQLINTEGER in the DM code.)

Chris Golledge
IBM Software Group, Lenexa KS
Tel: (913) 599 7250

"Ah, because I have learned something since last week."  - Gandhi

_______________________________________________
unixODBC-dev mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: sizeof SQL_ATTR_TXN_ISOLATION value

Nick Gorham-2
On 21/08/14 01:12, Chris Golledge wrote:

The Microsoft definition for the value is "A 32-bit bitmask ...".  The unixODBC driver manager implements this value as an int (SQLINTEGER).  The size of the int type is platform dependent.  On little endian systems, it works out OK for my driver to write only the first 32 bits (at least if the variable is initialized), but on a 64-bit, big endian system, like AIX (and I think Solaris), the app reading the value as a 64-bit integer when the driver has written the value into the high order bytes does not work.


But SQLINTEGER is not a platform dependent type. Its always 32 bit, it should map to whatever type is 32 bit signed on that platform. Once you remove that confusion I think the rest of the problem goes away.

If your platform gives you sizeof( SQLINTEGER) != 4 then thats the problem to look at.

BTW, you should preferably join the list to post.

--
Nick

_______________________________________________
unixODBC-dev mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Loading...