On 13-Dec-2005 David Dindorp wrote:
> Martin J. Evans wrote:
>> I was attempting to use perl DBI and the ping method to see if
>> the myodbc connection was still working and discovered that in
>> myodbc 3.51.12 (at least) ping always returns true.
> Sounds a bit like the Perl version of this issue:
> http://bugs.mysql.com/bug.php?id=14639 ?
> Issue details:
> The ConnectionState == open/closed mechanism in the .NET ODBC
> classes (corresponds to DBD::ODBC ping) doesn't work anymore
> after upgrading to 3.51.12.
> .NET uses an SQL_ATTR_CONNECTION_DEAD call to the ODBC
> driver to return the ConnectionState property's value.
It is in a similar area but I don't think the same. The problem with
SQL_ATTR_CONNECTION_DEAD has always been the statement in the spec which says
using asking for SQL_ATTR_CONNECTION_DEAD should NOT cause a round-trip to the
server. As a result, I'd never expect SQL_ATTR_CONNECTION_DEAD to be set until
AFTER a failure. i.e.
just asking for SQL_ATTR_CONNECTION_DEAD at any time will nearly always return
not dead but asking for it after an error might return dead if the driver now
knows the previous failing operation has caused it to lose connection to the
I may be wrong (the reference in the above URL to reconnection in particular)
but I think my case is more straight forward. Any call to SQLTables when the
server is dead does not return an error, neither do SQLDescribeCol, SQLBindCol
or SQLFetch and there is no hope of reconnection because the mysql server was
Surely, SQLTables should return an error if the server has gone away, unless
there is some sort of metadata caching going on.
To work around this I've had to implement my own DBI ping which does a
SQLPrepare/SQLExecute (the execute fails if the server is dead). However, I've
posted to the dbi-users list since as far as I can see DBI->ping will not work
for MySQL ODBC driver (3.51.12 at least).
Martin J. Evans
Easysoft Ltd, UK