Bug #26934 SQLTables behavior has changed
Submitted: 7 Mar 2007 21:15 Modified: 6 Jul 2007 4:43
Reporter: Joe Roberts
Status: Closed
Category:Connector/ODBC Severity:S1 (Critical)
Version:3.51.14GA OS:Microsoft Windows (Windows 2000 Server)
Assigned to: Bugs System Target Version:

[7 Mar 2007 21:15] Joe Roberts
Description:
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 22: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 17: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 18:46] Jess Balint
patch + test

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

[6 Jul 2007 4: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.