Bug #3797 Regression in MyODBC 3.51.07
Submitted: 17 May 2004 12:22 Modified: 13 Jul 2004 21:11
Reporter: Gary Ashford Email Updates:
Status: Closed Impact on me:
Category:Connector / ODBC Severity:S2 (Serious)
Version:3.51.07 OS:Windows (Win32)
Assigned to: Timothy Smith CPU Architecture:Any

[17 May 2004 12:22] Gary Ashford
In the latest release of the Windows32 MyODBC driver, the ODBC API call; SQLColumns conditionally fails to return information on AUTO_INCREMENT columns.
(The result set completely omits the row describing the AUTO_INCREMENT column.)

This occurs when the call to SQLColumns is immediately preceeded by a call to SQLPrimaryKeys to retreive primary key info. The result set generated by SQLPrimaryKeys correctly describes the AUTO_INCREMENT column (in our test table, this was column 1). Subsequently however the result set generated by SQLColumns omits column 1 but does return results for all other columns.

If the call to SQLPrimaryKeys (and subsequent result set processing operations) are omitted, SQLColumns will correctly return information on the AUTO_INCREMENT column.

This is a regression from version 3.51.06 which correctly returns information on AUTO_INCREMENT columns using both SQLColumns and SQLPrimaryKeys- consistent with the ODBC 3.x API

(We also note that in the Win32 ODBC Administrator "Drivers" section, the latest MyODBC driver is labelled with the wrong version string: 3.51.06 instead of 3.51.07)

How to repeat:
ODBC API calls should be executed in the following order:
SQLNumResultCols -> n
SQLDescribeCol * n
SQLFetchScroll until return status = SQL_NO_DATA
SQLNumResultCols -> n
SQLDescribeCol * n
SQLFetchScroll until return status = SQL_NO_DATA

This sequence is followed by the Omnis Studio ODBC Data Access Module (DAM) whenever a table is double-clicked using the graphical SQL Browser tool.
Using the Studio SQL-Browser logged on to MySQL 4.x using the 3.51.07 ODBC driver, it can be seen that tables containing AUTO_INCREMENT columns are not displayed correctly whereas using the older 3.51.06 driver they are.

Bertrand MattheliƩ (bertrand@mysql.com) is familiar with our product and should be able to verify the fault using his copy of Omnis Studio.

Suggested fix:
Analyse code changes made between versions 3.51.06 and 3.51.07 which could potentially corrupt the result set generated by SQLColumns, possibly code which is shared by the SQLPrimaryKeys call(?)

Please let me know if you are unable to reproduce the problem and I will attempt to write some standalone code which reproduces it.
[12 Jul 2004 23:01] Peter Harvey
test to try to show problem

Attachment: test.c (text/plain), 8.89 KiB.

[12 Jul 2004 23:02] Peter Harvey
I could recreate problem. I have attached a small C test program. Perhaps customer can provide more details and/or create a revised C program showing problem.
[12 Jul 2004 23:03] Peter Harvey
Previous message should read; "could NOT recreate problem"
[13 Jul 2004 14:24] Gary Ashford
Updated test.c now reproduces the problem.

Attachment: test.c (text/plain), 9.19 KiB.

[13 Jul 2004 14:26] Gary Ashford
Please see the newly uploaded 'test.c' program which now reproduces the problem.
Note that the statement handle needs to be global and re-used by both SQLPrimaryKeys and SQLColumns to see the problem.

[13 Jul 2004 18:50] Peter Harvey
Now see error. Debugging it.
[13 Jul 2004 18:51] Peter Harvey
Thanks for the update - I now see the error. There is a good chance that this is caused from some difference in the client library used to link the more recent ODBC driver. Will look into this today.
[13 Jul 2004 21:02] Peter Harvey
Problem was that catalog functions were not (with just a couple of exceptions) resetting the statement before loading it up with new data. This is corrected and the changes are now in source repository. Will be in next binary release. I have attached a revised test program as well.
[13 Jul 2004 21:02] Peter Harvey
revised test program

Attachment: test.c (text/plain), 10.94 KiB.

[13 Jul 2004 21:04] Peter Harvey
Using revised testing showed that almost all catalog functions failed to reset statement. Corrected and now in source repo. for next binary release.
[13 Jul 2004 21:11] Timothy Smith
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at

Additional info:

The fix will be available in version 3.51.09.