christopherbarsuk has asked for the wisdom of the Perl Monks concerning the following question:

Thanks to everyone who responded to my previous question regarding DBI -- I had my sysadmin upgrade to the latest (1.19) version of DBI, which includes the missing functions, and now I have those functions... Hooray.

But of course, I now have a different problem...

The disconnect function no longer works -- instead, it Croaks a message about "DBI->disconnect is not a DBI method." I investigated a bit, and found that there's a new function, DBI->disconnect_all ... however, this doesn't seem to do anything, because I still get those "Database handle destroyed without explicit disconnect" warnings.

I checked the MySQL module, and didn't find a disconnect method there.

So, where is the disconnect method supposed to be defined? Or, if I'm supposed to be using the disconnect_all method now, why isn't that working? Or, how can I define my own disconnect method? Or, why won't DBI play nice?

Thanks in advance to anyone who can help me out... I love Perl, and I like DBI, but sometimes they can frustrate the bejesus out of me...

Replies are listed 'Best First'.
Re: DBI-disconnect ???
by mattr (Curate) on Aug 12, 2001 at 15:06 UTC
    This looks like a subclassing bug. If you search google with the text of the error in quotes you will find references to this problem such as here(1), here(2), here(3) and here(4).

    Link 2 above has some code, and link 3 has the trace.

    The problem has hit people upgrading to DBI 1.15 from 1.13. If you post some code maybe we can find a similar problem where you might be having problems with inheritance like the code below from link 1.

    Re: DBI 1.15 subclassing bug! ---------------------------------------------------------------------- +---------- To: "dbi-users" <dbi-users@perl.org> Subject: Re: DBI 1.15 subclassing bug! From: "Phil R Lawrence" <prlawrence@Lehigh.EDU> Date: Mon, 9 Apr 2001 11:40:39 -0400 Cc: "Tim Bunce" <Tim.Bunce@ig.co.uk> Delivered-To: mailing list dbi-users@perl.org Mailing-List: contact dbi-users-help@perl.org; run by ezmlm References: <00a501c0bede$2b70be00$5b34b480@lehigh.edu> <2001040700050 +9.F20472@ig.co.uk> ---------------------------------------------------------------------- +---------- "Tim Bunce" <Tim.Bunce@ig.co.uk> wrote: > On Fri, Apr 06, 2001 at 05:11:38PM -0400, Phil R Lawrence wrote: > > Uncaught exception from user code: > > DBI->disconnect is not a DBI method... > I wouldn't want to call you a beginner, but somewhere, for some > reason, you're executing "DBI->disconnect" or "$foo->disconnect" > where $foo contains "DBI". You were kind to not call me a beginner! Nonetheless, the issue was a screwed up @ISA ordering. See below for the bug. I'm glad you added the code to make DBI->disconnect blow up in DBI 1.15. I learned a bit more about inheritance as a result. Thanks, Phil R Lawrence package STORIT; use SUBCLASS_DBI; use vars qw( @ISA ); @ISA = qw ( SUBCLASS_DBI ); sub new { my $proto = shift; my $class = ref($proto) || $proto; my $s = $class->test_connect or die; return $s; } #============================================================== package STORIT::db; use vars qw( @ISA ); @ISA = qw( STORIT SUBCLASS_DBI::db ); # ^^^^^^ # this caused disconnect invocation to be first looked # for as a DBI method (due to STORIT's @ISA) instead # of as a SUBCLASS_DBI::db method (which would have # correctly resolved as a DBI::db method). #============================================================== package STORIT::st; use vars qw( @ISA ); @ISA = qw(SUBCLASS_DBI::st);
      Aha! This looks like a similar problem to my own... I'm a relative beginner when it comes to inheritance, so I'm sure that's where my problem lies. Here's what I'm doing: I have a class, "class_X", which is a subclass of DBI, and another class, "class_Y", which is a subclass of class_X. class_X is fairly generic, and merely extends some of the DBI functionality; class_Y is more specific to my database needs. Here's some relevant code:
      package class_X; require DBI; @ISA = qw( DBI ); sub new { my( $class, $dns, $username, $password ) = @_; my %attr = ( PrintError => 1, RaiseError => 0, AutoCommit => 1 ); my $self = DBI->connect( $dns, $username, $password, \%attr ) or +return; push @ISA, ref $self if( not grep { $_ eq ref $self } @ISA ); return bless $self, $class; } sub DESTROY { my( $self ) = @_; $self->disconnect; } 1; package class_Y; require class_X; @ISA = qw( class_X ); sub new { my( $class ) = @_; my $dns = "DBI:mysql:database=XXX"; my $user = "XXX"; my $pwd = "XXX"; my $self = class_X->new( $dns, $user, $pwd ); return bless $self, $class; } sub DESTROY { my( $self ) = @_; $self->disconnect; } 1;

      This used to work fine (before upgrading DBI); now I'm having the same problem as mentioned in the links you (so graciously) forwarded.

      I haven't yet been able to wrap my brain around the problem and figure out exactly how to solve it... Any friendly nudges in the right direction?

        Okay, here is my off-the-cuff guess.

        Why not change package class_Y from
        @ISA = qw( class_X );
        to
        @ISA = qw( DBI class_X );

Re: DBI-disconnect ???
by MrCromeDome (Deacon) on Aug 12, 2001 at 02:31 UTC
    Unlike this case:
    my $database = DBI->connect("DBI:" . $info{DBMS} . ":" . $info{DSN}, 'sa','') or die "Could not connect to database: " . DBI->errstr;
    where you actually invoke the connect method in DBI, the disconnect method is part of your database object. You would want to do something more like this:
    $database->disconnect();
    Hope this helps!
    MrCromeDome
      Yep, that's what I've been doing all along...
      my $dbh = DBI->connect( $dsn, $user, $pwd, \%attr ); ... $dbh->disconnect;

      ...and it worked until my sysadmin upgraded to the latest DBI.

      Sorry if my original post was misleading.