|
|
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
--
Michael Peppler Data Migrations, Inc.
mpeppler@peppler.org *or* mpeppler@mbay.net
http://www.mbay.net/~mpeppler
International Sybase User Group: http://www.isug.com
|
