Thanks Jonathan,
Jonathan Leffler wrote:
DBD::Informix is careful about errors.
I would hope all DBDs are ;-)
Each statement handle keeps a copy of its most recent status/error
information out of the global sqlca variable (plus the sqlstate variable).
Each database handle has a copy of the most recently executed statement's
error/status information. Of course, this is made more complex by
AutoCommit which requires extra statements to be executed to simulate the
AutoCommit; you have to ignore the status of the extra statements when they
succeed, but record the error if they fail.
So, I think you are saying that if you executed the following with
DBD::Informix:
my $dbh = DBI->connect({RaiseError=>1});
eval {
$dbh->begin_work;
my $sth = $dbh->prepare(q/insert into table values (1)/);
$sth->execute; # execute fails - say duplicate key error
$dbh->commit;
};
$dbh->err here would be what $sth->err was above in the eval after the
execute (assuming you could have looked at $sth->err which you can't in
this case because RaiseError was set).
Yes?
I'm not actually using Informix (at the moment, Oracle, MySQL, DB2) but
we have spent a great deal of effort making sure we work with these 3
databases and don't want to rule out any others.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
On 1/23/07, Martin Evans <[EMAIL PROTECTED]> wrote:
From the DBI pod under "METHODS COMMON TO ALL HANDLES" for "err:
"The DBI resets $h->err to undef before almost all DBI method calls, so
the value only has a short lifespan. Also, for most drivers, the
statement handles share the same error variable as the parent database
handle, so calling a method on one handle may reset the error on the
related handles."
Given the "most drivers" above I presume some drivers don't share the
error variable for database and statement handles. Which are these
drivers? If you don't know of any, perhaps you can tell me how to find
out whether they do? I did find the following in DBI.pm:
sub _new_drh { # called by DBD::<drivername>::driver()
my ($class, $initial_attr, $imp_data) = @_;
# Provide default storage for State,Err and Errstr.
# Note that these are shared by all child handles by default! XXX
# State must be undef to get automatic faking in DBI::var::FETCH
my ($h_state_store, $h_err_store, $h_errstr_store) = (undef, 0, '');
The reason I'd like to know is that I have some circumstances where an
error occurs on a statement handle which goes out of scope immediately
so err is not available. I notice the connection handle (with
DBD::Oracle) also contains the same error number/string and this would
be great except for the fact we use multiple DBDs.
Thanks.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
