Re: DBI driver and transactions

Do you want autocommit on or off?

With autocommit off, use $dbh->rollback to do ROLLBACK followed by BEGIN
and use $dbh->commit to do COMMIT followed by BEGIN.

Don't use the $dbh->do stuff for that sort of thing.

It could be you, or could be DBI, depends on what you really want to do
(can't tell from your message). If you are trying to catch asynchronous
notices with autocommit off, DBI might not be a good choice.

But if you're trying to do run of the mill stuff, it's probably you :).

Link.

At 02:18 AM 2/3/03 +0000, Nigel J. Andrews wrote:
>I'm getting very odd behaviour and am getting quite frustrated at fighting
>this
>thing. So just so I know for the future does anyone know if there are problems
>with using transactions when using cached dbi handles?
>
>I was using my own caching of the handle(s) but I didn't have time to work out
>who, what, why and where someone was disconnecting it so switched to the DBI
>caching connect. Note, this is NOT persistent/pooled connections.
>
>However, either there is something wrong (and it's been fixed since I loaded
>the software) or I completely fail to grasp the concept of transactions as
>understood by DBI.
>
>With AutoCommit => 0 I see a BEGIN logged right before the
>first query I send...
>
>Oh I give up. Trying to clarify what happens when I'm now seeing rollbacks
>issued in AutoCommit => mode where I'm not doing any and it's certainly not me
>since I've got a trap on my interface layer to DBI for that and it's not been
>tripped at all.
>
>So,
>
>a) anyone know of any problems,
>
>b) can I assume it is me and not just give up on this DBI stuff in the
>future (
>I haven't got the time to rewrite my application now; not that I can't see it
>being a particularly onerous task for what I use from DBI )
>
>c) can I just issue BEGIN, COMMIT, ROLLBACK when I want to via normal
>$dbh->do(...) without causing myself even more problems?