On Mon, 2004-01-12 at 07:26, Tim Bunce wrote:
> In his announcement for DBD::Ingres-0.51 Henrik says:
>
> > The DBI docs state that swtiching the value of $dbh->{AutoCommit} from off
> > to on should cause a $dbh->commit to be called, but setting
> > $dbh->{ing_rollback} to on will cause a $dbh->rollback to be called instead.
> >
> > This is mainly usefull in situations where you normally have
> > $dbh->{AutoCommit}=1 and only in some subroutines change it to
> > $dbh->{AutoCommit}=0 using
> > local $dbh->{AutoCommit}=0;
> > to get it reverted to normal use no matter how you leave the subroutine.
> > In these cases it seems much more sensible to rollback any uncommited
> > transactions on resetting AutCommit than to have them commited.
>
> That seems like a very valid point to me. Commits should always be
> explicit not implicit. As it stands now this is very unsafe:
>
> $dbh->{RaiseError} = 1;
> eval {
> local $dbh->{AutoCommit} = 0;
> ...
> }
>
> What to others think of this issue? (Please ignoring for the moment
> any backwards compatibility issues with changing this and focus on the
> principle.)
I agree as well. The behavior defined in the spec was something that
surprised me a few months ago when I re-read the spec in response to a
user query, but didn't have the time to pursue completely at the time.
Michael
--
Michael Peppler Data Migrations, Inc.
[EMAIL PROTECTED] http://www.mbay.net/~mpeppler
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or
long term contract positions - http://www.mbay.net/~mpeppler/resume.html
