I've tested this on both 1.54 and 1.56; don't know if it exists prior to that, tho I'm fairly certain that it worked properly at some earlier release.
I have an app the reuses the $sth variable. Having prepared/executed/fetched for one statement, it proceeds to prepare a new (erroneous) statement, for which the DBD internally properly reports the error and calls $dbh->set_err() (all of which is reported in the traces). As $dbh->prepare returns undef in that instance, it causes the existing $sth variable to invoke its DESTROY logic, which in turn invokes the finish() logic on the $sth. In the traces, I see the error info being cleared before I can step into my finish() method, so I assume DBI's finish() is somehow intercepting the call and clearing the error info at that point. Why ? The error information was stored on the connection, *not* the statement handle. Shouldn't the error info be left alone, regardless whether the statement handle is being destroyed ? Is there some additional step I need to apply to assure the error info is retained ? Or is this a bug ? I'm currently working around it by re-invoking $dbh->set_err within $sth->DESTROY after everything's cleaned up (only if there's an outstanding error), but that seems a bit dangerous e.g., if $sth->DESTROY is being called in response to a $dbh->DESTROY. Dean Arnold Presicient Corp.
