Hi,
Peter Rabbitson (ribasushi) has pointed out a change I made back in 1.28 has
led to the possibility that set_err may get called during global destruction
with faulty ODBC drivers. In his case he does:
perl -Iblib/lib -Iblib/arch -MDBI -e 'my $dbh = DBI->connect("dbi:ODBC:xxx", "xxx","xxx", {
RaiseError => 1, AutoCommit => 1} ); my ($sth1, $sth2) = map { $dbh->prepare("SELECT 1") } 1..2; eval {
$sth1->execute } '
and with some versions of FreeTDS when one of the statement handles is cleaned
up in global destruction the call to SQLFreeStmt/SQLFreeHandle in DBD::ODBC
fails with SQL_ERROR but when SQLError/SQLGetDiagRec is called there is no
error. In this case, the change to DBD::ODBC was to call set_err saying
SQLFreeStmt failed but no error was obtained.
It makes no sense to do this during the global destruction phase. Is the
correct way to avoid this to wrap the call to set_err in:
if (!PL_dirty && !SvTRUE(get_sv("DBI::PERL_ENDING",0))) {
set_err
}
I wasn't sure about the PERL_ENDING bit.
I note that PL_dirty has been replaced in Perl 5.14 but #p5p suggested it is
still ok to use as a macro exists in perl.h.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
