|
|
sybperl-l Archive
Up Prev Next
From: Michael Peppler <mpeppler at peppler dot org>
Subject: Re: DBD::Sybase and Replication Server
Date: Jan 27 2005 3:23PM
On Thu, 2005-01-27 at 12:26, Avis, Ed wrote:
> It is possible to connect to Sybase Replication Server with
> DBD::Sybase. But whenever you do you get this error in the repserver
> logs:
>
> E. 2005/01/27 10:48:38. ERROR #14024 USER(sa) - /execint.c(1069)
> Executor does not allow the entered command in the current mode.
>
> I think this may be caused by the check for chained transactions which
> syb_db_connect() does. Or perhaps DBD::Sybase is sending 'begin tran'
> to the server. Replication server doesn't support any kind of
> transaction.
There are a couple of minor issues with DBD::Sybase and rep server.
First, with DBD::Sybase 1.04 and earlier the code uses a standard
prepare()/execute()/fetch() block in the connect() call to fetch the
@@version string. The problem with that is that AutoCommit is still
false at that time (it gets set by DBI *after* connect() returns), and
so a begin tran/commit tran combo gets issued.
In 1.05 the server version string is fetched by an ad-hoc C function, so
no begin tran/commit tran should be executed there. However, 1.05 tries
to check if the server supports the CHAINED_TXN capability, which sends
an error to the client with "no SRV_OPTION handler installed". That's
not a serious error, and I'll silence it in the next version.
Third, when DBI sets AutoCommit to TRUE (after the connect() returns)
the handler for this action generates a COMMIT call to be on the safe
side even though no transactions (or requests) of any sort have been
issued. That's pretty much what the DBI spec mandates, though I suppose
that DBD::Sybase could carry a flag in the $dbh that is set if any
command has been executed, so could avoid the commit if no command has
been executed.
Michael
--
Michael Peppler - mpeppler@peppler.org - http://www.peppler.org/
Sybase DBA/Developer
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
|
