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