Bug #59541 | Incorrect results when using SQLBindCol with row binding and indicator variables | ||
---|---|---|---|
Submitted: | 17 Jan 2011 4:00 | Modified: | 3 Jan 2013 22:18 |
Reporter: | amrith kumar | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Connector / ODBC | Severity: | S1 (Critical) |
Version: | mysql 5.1 | OS: | Linux (x86_64) |
Assigned to: | Bogdan Degtyariov | CPU Architecture: | Any |
[17 Jan 2011 4:00]
amrith kumar
[17 Jan 2011 4:01]
amrith kumar
Results from running the sample program. amrith@amrith-desktop64:~/virtualdb/tests$ ./row-binding sizeof(row) = 16 ROW_ARRAY_SIZE = 500 Binding 0x166dd80, 4, 0x166dd88 nrows = 2 0x166dd80 | 00000006 68676665 00000004 00000000 | 0x166dd90 | 00000014 78777675 00000004 00000000 | 0x166dda0 | 6A696867 6E6D6C6B 7271706F 76757473 | 0x166ddb0 | 7A797877 64636261 68676665 6C6B6A69 | 0x166ddc0 | 706F6E6D 74737271 78777675 62617A79 | 0x166ddd0 | 66656463 6A696867 6E6D6C6B 7271706F | 0x166dde0 | 76757473 7A797877 64636261 68676665 | 0x166ddf0 | 6C6B6A69 706F6E6D 74737271 78777675 | 0x166de00 | 62617A79 66656463 6A696867 6E6D6C6B | 0x166de10 | 7271706F 76757473 7A797877 64636261 | setting rowsize to 12 Binding 0x166dd80, 4, 0x166dd84 nrows = 2 0x166dd80 | 00000006 00000004 00000000 00000004 | // This is the error 0x166dd90 | 00000000 78777675 62617A79 66656463 | // The value for row 2, 0x166dda0 | 6A696867 6E6D6C6B 7271706F 76757473 | // a = 20 is nowhere to be 0x166ddb0 | 7A797877 64636261 68676665 6C6B6A69 | // seen. 0x166ddc0 | 706F6E6D 74737271 78777675 62617A79 | 0x166ddd0 | 66656463 6A696867 6E6D6C6B 7271706F | 0x166dde0 | 76757473 7A797877 64636261 68676665 | 0x166ddf0 | 6C6B6A69 706F6E6D 74737271 78777675 | 0x166de00 | 62617A79 66656463 6A696867 6E6D6C6B | 0x166de10 | 7271706F 76757473 7A797877 64636261 |
[17 Jan 2011 9:45]
Valeriy Kravchuk
What exact Connector/ODBC version do you use?
[17 Jan 2011 13:36]
amrith kumar
Here is the information you requested. If you'd like some other information about the driver, please let me know. Thanks! SQL_DRIVER_VER: 05.01.0006 SQL_DRIVER_ODBC_VER: 03.51 SQL_DRIVER_NAME: libmyodbc5.so SQL_DM_VER: 03.52.0002.0002 SQL_DBMS_VER: 5.1.49-1ubuntu8.1 SQL_DBMS_NAME: MySQL
[20 Jan 2011 7:09]
Bogdan Degtyariov
Hi Amrith, Have you tried MySQL Connector/ODBC 5.1.8? This version has several fixes related to row binding since your current driver release 5.1.6. One more question, which driver manager you are using? Is that UnixODBC, iODBC, DataDirect or something else? Which version? Thanks.
[20 Jan 2011 9:14]
amrith kumar
Bogdan, No, I have not been able to successfully run my test program with 5.1.8. I have installed the driver by downloading mysql-connector-odbc-5.1.8-linux-glibc2.3-x86-64bit.tar.gz, unpacking it, and pointing my .odbc.ini to the new libmyodbc5.so. I am unable to connect to the database (i.e. SQLConnect() fails) and any attempt to get more error information causes SQLGetDiagRec() to fail. So, I'm not sure how to use just the new ODBC driver and not upgrade a whole bunch of other things. If you could help me with that upgrade, I'm happy to retry with 5.1.8. As for DM, I'm using unixODBC and the previous update has the DM Version. -amrith
[20 Jan 2011 11:52]
Bogdan Degtyariov
Amrith, Thanks for answering my questions. Analyzing your last reply I noticed one thing: if SQLConnect() fails the driver (libmyodbc5.so) does not get loaded and therefore the diagnostic call SQLGetDiagRec() is completely handled by the driver manager (UnixODBC). This brings us to the conclusion that SQLGetDiagRec() failure has nothing to do with MySQL ODBC driver. It actually points to the problem between your application and the driver manager. It is important to make sure that 64-bit client application is always loading 64-bit driver manager library (libodbc.so). SQLConnect() could fail if libodbc.so is attempted to be loaded dynamically, but the library contains 32-bit code. Also, .odbc.ini is not the standard configuration file name for UnixODBC. In order to be able to find this file you have to set the environment variable ODBCINI=path_to_odbc_ini/.odbc.ini I hope this will help to establish the connection from MyODBC driver 5.1.8
[20 Jan 2011 14:14]
amrith kumar
Bogdan, I'm trying to understand your reply. You write: "Analyzing your last reply I noticed one thing: if SQLConnect() fails the driver (libmyodbc5.so) does not get loaded and therefore the diagnostic call SQLGetDiagRec() is completely handled by the driver manager (UnixODBC). This brings us to the conclusion that SQLGetDiagRec() failure has nothing to do with MySQL ODBC driver. It actually points to the problem between your application and the driver manager." All I did was change the driver path in my .odbc.ini as below: amrith@amrith-desktop64:~$ diff .odbc.ini.1 .odbc.ini.2 11c11 < Driver = /usr/lib/odbc/libmyodbc.so --- > Driver = /usr/lib/odbc/libmyodbc5.so amrith@amrith-desktop64:~$ And I'm unable to get connected to the database. My existing libmyodbc.so is 64 bit, just as the new one appears to be. amrith@amrith-desktop64:~$ objdump -f /usr/lib/odbc/libmyodbc.so /usr/lib/odbc/libmyodbc.so: file format elf64-x86-64 architecture: i386:x86-64, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x000000000000ecb0 amrith@amrith-desktop64:~$ objdump -f /usr/lib/odbc/libmyodbc5.so /usr/lib/odbc/libmyodbc5.so: file format elf64-x86-64 architecture: i386:x86-64, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x000000000005d850 amrith@amrith-desktop64:~$ So, there's more to switching ODBC drivers than just putting the new driver in the right place and pointing to it. And, the fact that changing the path in .odbc.ini makes the program stop (or start) working, means the DM is loading it. With that said, I am sure you have a system with the latest driver. Would you be able to take the simple sample program I provided and run it on your system? It is important to make sure that 64-bit client application is always loading 64-bit driver manager library (libodbc.so). SQLConnect() could fail if libodbc.so is attempted to be loaded dynamically, but the library contains 32-bit code. Also, .odbc.ini is not the standard configuration file name for UnixODBC. In order to be able to find this file you have to set the environment variable ODBCINI=path_to_odbc_ini/.odbc.ini I hope this will help to establish the connection from MyODBC driver 5.1.8
[21 Jan 2011 8:43]
Bogdan Degtyariov
Repeated the problem using Connector/ODBC 5.1.8. Setting the report status to "Verified".
[3 Jan 2013 22:18]
John Russell
Added to changelog for 5.2.3: On a 64-bit system, calls to the SQLBindCol function using indicator variables (through the last parameter) could return incorrect results.