Re: DBI driver and transactions - Mailing list pgsql-general

From Nigel J. Andrews
Subject Re: DBI driver and transactions
Date
Msg-id Pine.LNX.4.21.0302030926300.20150-100000@ponder.fairway2k.co.uk
Whole thread Raw
In response to Re: DBI driver and transactions  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
List pgsql-general
On Mon, 3 Feb 2003, Nigel J. Andrews wrote:

> On Mon, 3 Feb 2003, Christoph Dalitz wrote:
>
> > > Date: Mon, 3 Feb 2003 02:18:11 +0000 (GMT)
> > > From: "Nigel J. Andrews" <nandrews@investsystems.co.uk>
> > >
> > > With AutoCommit => 0 I see a BEGIN logged right before the
> > > first query I send...
> > >
> > This is in compliance to the SQL2 standard, which says that
> > transactions implicitly begin with the first DML command after
> > the last commit/rollback. As Postgres has explicit transaction
> > beginning, the DBD-Pg driver must emulate the SQL2 behaviour by
> > automatically issuing a BEGIN statement.
> >
> > DBI provides the methods begin(), commit() and rollback() for
> > transaction management; begin() usually does nothing and thus
> > does no harm when you call it.
>
> Thanks for the replies folks.
>
> [lots of my blurb edited out]
>
> So any ideas what this message on that commit is?
>
> disconnect(DBI::db=HASH(0x87af40c)) invalidates 1 active statement. Either destroy statement handles or call finish
onthem before disconnecting. at /home/nandrews/src/www/lib/LtS/perl/DB.pm line 128. 
>         DB::disconnect('Delegate=HASH(0x87afeb0)') called at /my/directory/modulesA/DB.pm line 144
>         DB::DESTROY('Delegate=HASH(0x87afeb0)') called at /my/directory/modules/BookingSummaryPage.pm line 142
>         eval {...} called at /my/directory/modules/BookingSummaryPage.pm line 142
>
> [lots of my blurb edited out]
>
> I fail to see where I'm going wrong and what that error message is really
> saying. I'm going to switch to using normal connects to see if that makes any
> difference, although I'm pretty sure I was getting similar messages at an
> earlier stage of development before I switched away from my own connection
> caching to use DBI's.
>
> BTW, is there a better list for discussing such DBI questions?
>

One that did also occur to me is that I don't call finish before methods which
have done prepare/execute and that many times I don't use a loop to retrieve
data until one of the fetchrow_...() methods says there isn't any left. Could
this be the cause of my problems? Somehow messing with DBI's mind and making it
run out of statment handles? It does say finish or destroy handle and the
handles should be destroyed when they drop out of scope shouldn't they?


--
Nigel J. Andrews


pgsql-general by date:

Previous
From: "Nigel J. Andrews"
Date:
Subject: Re: DBI driver and transactions
Next
From: Mark Kirkwood
Date:
Subject: Re: Postgre vs SAP Db