Bug #26934 SQLTables behavior has changed
Submitted: 7 Mar 2007 20:15 Modified: 6 Jul 2007 2:43
Reporter: Joe Roberts Email Updates:
Status: Closed Impact on me:
Category:Connector / ODBC Severity:S1 (Critical)
Version:3.51.14GA OS:Windows (Windows 2000 Server)
Assigned to: Jess Balint CPU Architecture:Any

[7 Mar 2007 20:15] Joe Roberts
The behavior for SQLTables has changed.  We use the code to determine if a connection to the MySQL server is stale.  With the old driver version:

DriverName=<myodbc.dll>, DriverVer=<2.50.39>, DriverODBCVer=<02.50>

SQLTables returned an error code when the connection was stale.

With the new driver:

SQLTables returns 0.

How to repeat:
Create a table in a database on the MySQL server and set the wait_timeout variable to 15 seconds and restart the server so the new setting takes place.

Use test code to connect to the database and then wait more than 15 seconds, after which the Server will drop the connection, then call SQLTables in the test code with the table name - with the old driver it returns an error code - with the new driver it returns zero.
[7 Mar 2007 21:02] Steven Saunders
SQLTables() also returns 0 (SUCCESS) and no error code is set if it called after the connection is invalided, not just a timeout on the server side.  Server could be stopped, restarted, etc.
[11 Apr 2007 15:05] Tonci Grgin
Hi Joe and thanks for your report.

Verified as described with MyODBC 3.51.14GA using generic MS ODBC client odbcte32.exe (which btw. crashed:) on GetDataAll ).

In no way should we return SQL_SUCCESS, but for time being, 3.51.14 has Reconnect property which helps (if checked of course).
[21 Jun 2007 16:46] Jess Balint
patch + test

Attachment: bug26934.diff (application/octet-stream, text), 11.44 KiB.

[6 Jul 2007 2:43] Paul DuBois
Noted in 3.51.17 changelog.

Fixed error handling of out-of-memory and bad connections in catalog
functions. This might raise errors in code paths that had ignored
them in the past.