Dean Arnold wrote:
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 ?
Pardon the interruption (2 weeks of fighting UNICODE demons has left
me severely brain damaged).
I now realize that DESTROY shouldn't call finish() directly,
since finish() is a "normal" method that should clear error info
if it completes OK. I've changed to use a private version
of finish(), and all is well.
Dean Arnold
Presicient Corp.
