Michael Peppler
Sybase Consulting
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
Sybase on Linux FAQ
Sybperl FAQ
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

From: Michael Peppler <mpeppler at peppler dot org>
Subject: Re: DBI/DBD::Sybase error handling issues
Date: Apr 24 2002 3:06PM

On Wed, 2002-04-24 at 07:36, Michael Burstin wrote:
> On Wed, Apr 24, 2002 at 07:27:09AM -0700, Michael Peppler wrote:
> > On Wed, 2002-04-24 at 07:15, Michael Burstin wrote:
> > > I am once again running into some "interesting" error handling
> > > sitations.  I have a set of scripts which are actually causing a
> > > Sybase stacktrace, but in this, I discovered that I am not actually
> > > catching the Sybase error in my DBI code.  I am in a situation where
> > > $DBI::errstr is being set, however, $DBI::err is not!  I thought that
> > > this was an impossible state to get into (I thought they were directly
> > > tied together, errstr only getting set if err is set).

> > Are you *sure* that the code below causes the 5702 error? Isn't it
> > the DISK INIT call that would cause the error?
> Yes.  It definatly happens in the create database statement.  I even
> tried running the SQL itself from an isql prompt, and I get the
> following:

> 1> create database archive on   archive_data = '1000m'
> 2> log on   logs = '500m'
> 3> go
> The SQL Server is terminating this process.

As you can see, isql doesn't get an error number either.

Which means that DBD::Sybase won't set $DBI::err to anything - there is
no error number.

This also means that no ct_*() calls actually return CS_FAIL or
CS_CMD_FAIL, as shown by the trace, which makes it difficult to catch.

The best that I can think of is to try to catch the error in the ad-hoc
handler via a pattern match on the error string.

Michael Peppler                              Data Migrations, Inc.           *or*
International Sybase User Group: