Yes, they are very old but my client does like to bother its SA/DBA. That's why
I am trying to subclassing the DBI directly for cleaning and consolidating bad
designed and implemented old modules.
Frequently there are multiple DBI handles in one script and in some cases a
script may use some modules and open more handles. It is not easy to silent the
warning by END block. As I am doing OO, I like the handles themselves can do
cleanup and be silent.
I tried adding MyDBI::db::DESTROY, but it triggered message as below:
DBI handle cleared whilst still active at ./OO_mydbh.pl line 13.
DBI Handle has uncleared implementors data at ./OO_mydbh.pl line
13.
dbih_clearcom (dbh 0x82fd28c 0x8288700, com 0x81f7a40, imp DBD::Oracle::db):
FLAGS 0x93: COMSET IMPSET Warn RaiseError
PARENT DBI::dr=HASH(0x82fd2bc)
KIDS 0 (0 Active)
IMP_DATA undef
________________________________
From: David E. Wheeler <da...@kineticode.com>
To: tiger peng <tigerpeng2...@yahoo.com>
Cc: "dbi-users@perl.org" <dbi-users@perl.org>
Sent: Wednesday, August 24, 2011 11:52 AM
Subject: Re: Turn off "Issuing rollback..." warning for AutoCommit.
On Aug 24, 2011, at 7:51 AM, tiger peng wrote:
> I am subclassing DBI for authenticating purpose by overwriting connection.
>
> I try to turn off warning message "Issuing rollback() for database handle
> being DESTROY'd without explicit disconnect()" by explicitly issuing
> rollback, disconnect and set AutoCommit to 0 without success. Could you
> please provide any solution and/or suggestion? My environment is quite old
> (Perl/5.80; DBI/1.30; DBD::Oracle/1.12).
Well first of all, upgrade Perl and those modules, if at all possible. That DBI
is NINE YEARS OLD!
As for the warning, what I generally do is disconnect in an END block right
after I connect, like so:
my $dbh = DBI->connect('dbi:Oracle:...');
END {
$dbh->disconnect if $dbh }
I also recommend against having AutoCommit set to 0, as that means you have a
transaction open all the time. You should just use transactions when you have
reason to use them, that is for database writes.
Best,
David
