List:MySQL ODBC« Previous MessageNext Message »
From:David Dindorp Date:December 15 2005 10:58am
Subject:RE: Some metadata functions not spotting mysql server is dead and disappearing tables
View as plain text  
Martin J. Evans wrote:
> 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.

That was the behaviour before 3.51.12.

> 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 server.

Also the behaviour before 3.51.12.
With 3.51.12 it seems that SQL_ATTR_CONNECTION_DEAD
just returns "not dead", always.

> 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 stopped.

I remain unconvinced that we're not seeing
the same since the symptoms are extremely similar.

But then again I know nothing of MyODBC internals.

I'm just sort of imagining that the calls you
mentioned internally uses the same mechanics as
SQL_ATTR_CONNECTION_DEAD to determine whether the
connection is alive.

> 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).

I had to use a similar workaround :-).
This should really be fixed (both, if they are in fact
separate problems) before more people upgrade to 3.51.12..

Thread
Some metadata functions not spotting mysql server is dead and disappearing tablesMartin J. Evans13 Dec
RE: Some metadata functions not spotting mysql server is dead and disappearing tablesDavid Dindorp13 Dec
  • RE: Some metadata functions not spotting mysql server is dead and disappearing tablesMartin J. Evans13 Dec
RE: Some metadata functions not spotting mysql server is dead and disappearing tablesDavid Dindorp15 Dec
  • RE: Some metadata functions not spotting mysql server is dead and disappearing tablesMartin J. Evans15 Dec
RE: Some metadata functions not spotting mysql server is dead and disappearing tablesDavid Dindorp16 Dec