On Tue, Apr 20, 2004 at 01:47:10PM +0530, Jason E. Stewart wrote: > Tim Bunce <[EMAIL PROTECTED]> writes: > > > > Here's the script: > > > > Ah, okay. Looking at the trace I see what's going on. > > > > The connect_cached() method perhaps ought to explicitly reset the > > error state of the $dbh because it's separate to the $dbh error > > state and the $dbh method calls it uses don't reset the state implicitly. > > > > The same applies to prepare_cached(). > > > > However, I'm not 100% sure I want to do that right now as I'd rather people > > only used $DBI::err after the preceding method call indicates an error > > (usually by returning false). > > Question: Are $DBI::err and $DBI::errstr guaranteed to be in a correct > state after other methods?
In theory (and assuming the driver does-the-right-thing :) but there are some subtle issues owing to the inter-relationship between those variables and $DBI::lasth (to name but one). > It seems like it would be nice if there was a small section in the man > page that simply said something like: > > $DBI::err - the error code of the last DBI method call. > $DBI::errstr - the error message of the last DBI method call. > > NOTE: the values of these variables is guaranteed to be valid only > after a method has failed. But if the DBI actually enforced that by, for example, never clearing them and just updating them when an error occurred, it would break a lot of code. I'll add something to the docs for now and aim to improve the situation for DBI v2. Tim.
