This is a copy of a bug I just reported to the author of
Exception::Class::DBI.
I've forwarded it here because having gone through some preliminary
analysis,
I'm not sure if the cause of the problem lies with Exception::Class::DBI or
with
DBI or DBD::Oracle.
Read further down for the specifics, but the meat of the problem seems to be
that
while the DBI documentation says this about the "CursorName" attribute:
"CursorName" (string, read-only)
Returns the name of the cursor associated with the
statement handle, if available. If not available or if
the database driver does not support the "where current
of ..." SQL syntax, then it returns "undef".
But in my experience, when you ask for $sth->{CursorName} inside of an
errorhandler
such as is used in Exception::Class::DBI, you generate a fatal error.
Because
Exception::Class::DBI uses this idiom to throw an exception:
} elsif (UNIVERSAL::isa($dbh, 'DBI::st')) {
# Throw a statement handle exception.
die Exception::Class::DBI::STH->new
( @params,
num_of_fields => $dbh->{NUM_OF_FIELDS},
num_of_params => $dbh->{NUM_OF_PARAMS},
field_names => $dbh->{NAME},
type => $dbh->{TYPE},
precision => $dbh->{PRECISION},
scale => $dbh->{SCALE},
nullable => $dbh->{NULLABLE},
cursor_name => $dbh->{CursorName},
param_values => $dbh->{ParamValues},
statement => $dbh->{Statement},
rows_in_cache => $dbh->{RowsInCache}
);
The error that comes back to the application is a plain string rather than
an object, and
the string contains information about why the exception-throwing mechanism
failed, not about
the event which caused the exception-throwing mechanism to be invoked in the
first place.
Thanks.
--
j.
James FitzGibbon
Consultant, Ajilon Services, TTS-3D@CC-950
[EMAIL PROTECTED]
voice/fax 612-304-6161/3277
-----Original Message-----
From: Exception-Class-DBI [mailto:bug-Exception-Class-DBI@;rt.cpan.org]
Sent: Tuesday, November 05, 2002 8:11 AM
To: [EMAIL PROTECTED]
Subject: [cpan #1764] AutoReply: Throwing an DBI::st exception fails
using DBD::Oracle
Greetings,
This message has been automatically generated in response to your
bug report about Exception-Class-DBI, a summary of which appears below.
There is no need to reply to this message right now. Your bug in
Exception-Class-DBI has been assigned an ID of [cpan #1764]. Please include
the string:
[cpan #1764]
in the subject line of all future correspondence about this issue. To do so,
you may reply to this message.
Thank you,
[EMAIL PROTECTED]
-------------------------------------------------------------------------
I'm using DBI 1.30 and DBD::Oracle 1.12 (RDBMS is 8.0.5)
Given this small program:
--START--
use DBI;
use Exception::Class::DBI;
use Data::Dumper;
my $dbh = DBI->connect(
'dbi:Oracle:', 'scott', 'tiger',
{ RaiseError => 0,
PrintError => 0,
HandleError => Exception::Class::DBI->handler, },
);
my $sth = $dbh->prepare("SELECT rowid FROM foo WHERE rowid = ?");
eval { $sth->execute() };
if( UNIVERSAL::isa($@, 'Exception::Class::DBI') ) {
print Dumper $@;
}
else {
print "non-object exception $@\n";
}
---END---
I get this error back:
non-object exception Can't get DBI::st=HASH(0x2004515c)->{CursorName}:
unrecognised attribute at /home_dir/jfitzgi/myperl/lib/Exception/Class.pm
line 225.
>From a grep of the DBD::Oracle source code, it would appear that CursorName
is not supported
with this DBD. Unfortunately, when an unrecognized attribute is asked for
inside of a DBI
ErrorHandler, the handler seems to die, so the exception thrown is just a
plain string, not
an Exception::Class object.
If I comment out this line in Exception/Class/DBI.pm, the problem goes away:
cursor_name => $dbh->{CursorName},
and I get an Exception::Class::DBI::STH thrown from the execute call. It
would appear that
(at least in my environment) that CursorName is the only attribute that is
missing from the
DBI implementation.
The DBI documentation says that CursorName should return undef if the
database engine doesn't
support that feature. I'm going to post this report to dbi-users and see if
anyone there can
shed some light on things.
Thanks.
