Bizarre ASE bug triggered by latest test DBD::Sybase

I believe the current (1.05.xx) test release of DBD::Sybase has changed
to use 'chained mode' if AutoCommit is off.  This has tickled a Sybase
bug which didn't appear with earlier DBD::Sybase versions.  Here's the
test program:

use warnings;
use strict;
use DBI;

my $dbh = DBI->connect('dbi:Sybase:server=IT_LN;database=fdenterprise_test', 'myuser', 'mypassword',
        { RaiseError => 1, AutoCommit => 0 });
#$dbh->do('set chained off');
my $sql = "SELECT
             sc.name,st.name,sc.length, CASE WHEN (sc.status & 8 = 8) THEN 1 ELSE 0 END
        FROM
             syscolumns sc,systypes st
        WHERE
             id = (select id from sysobjects where type='U' and name='addr')
        AND
             st.usertype = sc.usertype
        ORDER BY
             colid";
$dbh->do($sql);
disconnect $dbh;

This gives the error

DBD::Sybase::db do failed: Server message number=7713 severity=16 state=2 line=1 server=IT_LN text=Stored procedure '*ss1492368299_0739474268ss*' may be run only in unchained transaction mode. The 'SET CHAINED OFF' command will cause the current session to use unchained transaction mode.

Bizarre - I didn't call any stored procedure.  What is odder still is
that any change to the SQL text, even adding a newline on the end, stops
the error happening.  So I suspect some horrible memory trampling inside
Sybase.

Sure enough if I call 'set chained off' the problem goes away - but it
also subsides with an explicit 'set chained on'...

This isn't a bug in the new DBD::Sybase but it is a symptom of the
proposed behaviour change.  Has anyone else seen anything similar?

BTW, @@version contains

Adaptive Server Enterprise/12.5.3/EBF 12143/P/Sun_svr4/OS 5.8/ase125x/1883/32-bit/FBO/Fri Nov 12 03:23:21 2004

and the client machine is Linux RHEL3 with OCS-12.5.

-- 
Ed Avis <[email protected]>