sizeof SQL_ATTR_TXN_ISOLATION value
Chris Golledge <[email protected]> Wed, 20 Aug 2014 19:12:53 -0500
| Newsgroups | gmane.comp.db.unixodbc.devel |
|---|---|
| Message-ID | <OF1445E177.54FDD699-ON86257D3A.008108E7-86257D3B.00012E35@us.ibm.com> |
--===============1617936034== Content-type: multipart/alternative; Boundary="0__=09BBF7A9DF128E778f9e8a93df938690918c09BBF7A9DF128E77" Content-Disposition: inline --0__=09BBF7A9DF128E778f9e8a93df938690918c09BBF7A9DF128E77 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable 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 th= e 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 rema= in 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-b= its 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= --0__=09BBF7A9DF128E778f9e8a93df938690918c09BBF7A9DF128E77 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> <p><font size=3D"2" face=3D"sans-serif">The Microsoft definition for th= e value is "</font><font size=3D"3" face=3D"serif">A 32-bit bitmas= k </font><font size=3D"2" face=3D"sans-serif">...". The unix= ODBC 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 ord= er bytes does not work.</font><br> <br> <font size=3D"2" face=3D"sans-serif">There is no mention per se of this= attribute at </font><a href=3D"http://www.unixodbc.org/doc/ODBC64.html= "><font size=3D"2" face=3D"sans-serif">http://www.unixodbc.org/doc/ODBC= 64.html</font></a><font size=3D"2" face=3D"sans-serif"> or </font>= <a href=3D"http://support.microsoft.com/kb/298678"><font size=3D"2" fac= e=3D"sans-serif">http://support.microsoft.com/kb/298678</font></a><font= size=3D"2" face=3D"sans-serif">, so, you might say that since it was o= riginally a 32-bit mask, and there is no mention of it, it should remai= n 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 se= t with SQLSetConnectOption, and there is the change in the table that</= font> <table border=3D"1"> <tr valign=3D"top"><td width=3D"180" valign=3D"middle"> <ul style=3D"padding-left: 2pt"><font size=3D"3" face=3D"Verdana">SQLSe= tConnectOption</font></ul> </td><td width=3D"201" valign=3D"middle"> <ul style=3D"padding-left: 2pt"><font size=3D"3" face=3D"Verdana">SQLUL= EN Value</font></ul> </td></tr> </table> <br> <font size=3D"2" face=3D"sans-serif">and SQLSetConnectOption maps to SQ= LSetConnectAttr.</font><br> <br> <font size=3D"2" face=3D"sans-serif">Is there a better explanation for = why this attribute value becomes 64-bits on AIX? </font><br> <font size=3D"2" face=3D"sans-serif">(Being pedantic, if this logic is = correct, I'm thinking it should be declared as an </font><font size=3D"= 3" face=3D"Verdana">SQLULEN </font><font size=3D"2" face=3D"sans-serif"= > instead of an SQLINTEGER in the DM code.)</font><br> <br> <font size=3D"2" face=3D"sans-serif">Chris Golledge<br> IBM Software Group, Lenexa KS<br> Tel: (913) 599 7250<br> <br> "Ah, because I have learned something since last week."  = ;- Gandhi<br> </font></body></html>= --0__=09BBF7A9DF128E778f9e8a93df938690918c09BBF7A9DF128E77-- --===============1617936034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ unixODBC-dev mailing list [email protected] http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev --===============1617936034==--