Re: most drivers share error variable for sth/dbh handles?



DBD::Informix is careful about errors.

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.

On 1/23/07, Martin Evans <martin.evans@xxxxxxxxxxxx> 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




--
Jonathan Leffler <jonathan.leffler@xxxxxxxxx> #include <disclaimer.h>
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
"I don't suffer from insanity - I enjoy every minute of it."


Relevant Pages

  • Re: back to business.... (database technology)
    ... Exposes any DBX4-compliant database as an ADO.NET 2.0 data source. ... Unified metadata used for both DBX4 and ADO.NET drivers. ... SQLDatastore is a simple to deploy, fully managed, ... DbExpress Server ...
    (borland.public.delphi.non-technical)
  • Re: back to business.... (database technology)
    ... Exposes any DBX4-compliant database as an ADO.NET 2.0 data source. ... Unified metadata used for both DBX4 and ADO.NET drivers. ... SQLDatastore is a simple to deploy, fully managed, ... DbExpress Server ...
    (borland.public.delphi.non-technical)
  • Re: back to business.... (database technology)
    ... Exposes any DBX4-compliant database as an ADO.NET 2.0 data source. ... Unified metadata used for both DBX4 and ADO.NET drivers. ... SQLDatastore is a simple to deploy, fully managed, ... DbExpress Server ...
    (borland.public.delphi.non-technical)
  • Re: Microsoft Access ODBC Driver for Vista 64 bit
    ... I have an Access database with linked ... I tried setting up a System DSN through ODBC drivers in the ... It would not let me set a Machine connection, ... shows up as a User DSN in the ODBC drivers via Control Panel. ...
    (microsoft.public.windows.vista.general)
  • Re: dlopen(), atexit() crash on FreeBSD (testcase included)
    ... libdbi is a library for programs which are supposed to be able to ... access different database engines with a unified API. ... loads available database drivers at runtime via dlopencalls. ... FreeBSD invariably causes a segfault when the application linked ...
    (freebsd-hackers)