It's a bug, but one that isn't quite trivial to fix - the code would have to track "use xxxx" requests, and store those in the primary handle.

But a similar problem could occur if you executed a "use xxx" on a secondary handle. The whole issue of having multiple statement handles for one $dbh (which forces multiple connections) is a little shaky, unfortunately.

Michael

Hi Michael, great to see you here!

Now to the problem:

Perhaps it's not that hard. You filter three informal messages (5701, 5703, 5704) comming from the server.
AFAIK one of them is an 'environment' message, telling the client that the current database has changed.
You could use this message, to determine whether the database has changed.

btw. I could use this message too in a small project i'm doing at the moment. :-)
It's not hard to change DBD::Sybase, but it's not easy to have DBD::Sybase compiled in some win32 environments, so i have to wait for activestate :-(

Ah, yes, good idea.

I'll take a look to see how hard that might be, and how correct it would be.

Also - I'd have to be reasonably sure that MS-SQL returns the same message number for this...

Michael

Well - it's only taken two years :-(, but this is finally fixed in DBD::Sybase 1.01, which should be on CPAN now.

Michael