Bug when settings AutoCommit?
am 17.07.2007 04:15:08 von gzaven
I am unable to set the value of AutoCommit, RaiseError, or PrintError.
The following code...
$attr_ref->{RaiseError} = $self->{dbh}->{RaiseError};
$attr_ref->{PrintError} = $self->{dbh}->{PrintError};
$attr_ref->{AutoCommit} = $self->{dbh}->{AutoCommit};
$self->{dbh}->{RaiseError} = 1;
$self->{dbh}->{PrintError} = 0;
$self->{dbh}->{AutoCommit} = 0;
....gives me this output:
DBI::db=HASH(0x12dd470) trace level set to 0x0/1 (DBI @
0x0/214748364800) in DBI 1.58-ithread (pid 12248)
<- FETCH('RaiseError')= 1 at DBLayer.pm line 108
<- FETCH('PrintError')= 1 at DBLayer.pm line 109
<- FETCH('AutoCommit')= 1 at DBLayer.pm line 110 # these
three are OK
<- STORE('RaiseError' 1)= 1 at DBLayer.pm line 111
<- STORE('PrintError' 0)= 1 at DBLayer.pm line 112
<- STORE('AutoCommit' 0)= 1 at DBLayer.pm line 113 # these three
seem wrong
Notice the funky syntax in the last three lines. Why are the 1s and 0s
inside of the parens of STORE? Indeed, checking their values
immediately after this shows that all three vars are still set to 1;
my changes did not take effect.
This seems like a bug in DBI, but surely others would have found it?
I just upgraded to 1.58 from 1.54, and see the same problem in both
versions. Any ideas would be appreciated. Maybe I could turn on more
verbose DBI output?
Z
Re: Bug when settings AutoCommit?
am 17.07.2007 11:04:29 von Tim.Bunce
On Tue, Jul 17, 2007 at 02:15:08AM -0000, zaven wrote:
> I am unable to set the value of AutoCommit, RaiseError, or PrintError.
> The following code...
>
> $attr_ref->{RaiseError} = $self->{dbh}->{RaiseError};
> $attr_ref->{PrintError} = $self->{dbh}->{PrintError};
> $attr_ref->{AutoCommit} = $self->{dbh}->{AutoCommit};
> $self->{dbh}->{RaiseError} = 1;
> $self->{dbh}->{PrintError} = 0;
> $self->{dbh}->{AutoCommit} = 0;
>
> ...gives me this output:
> DBI::db=HASH(0x12dd470) trace level set to 0x0/1 (DBI @
> 0x0/214748364800) in DBI 1.58-ithread (pid 12248)
> <- FETCH('RaiseError')= 1 at DBLayer.pm line 108
> <- FETCH('PrintError')= 1 at DBLayer.pm line 109
> <- FETCH('AutoCommit')= 1 at DBLayer.pm line 110 # these three are OK
> <- STORE('RaiseError' 1)= 1 at DBLayer.pm line 111
> <- STORE('PrintError' 0)= 1 at DBLayer.pm line 112
> <- STORE('AutoCommit' 0)= 1 at DBLayer.pm line 113 # these three seem wrong
>
> Notice the funky syntax in the last three lines. Why are the 1s and 0s
> inside of the parens of STORE?
That's just the way the DBI trace log works at that trace level.
(I may change that for the next release to reduce the risk of confusion.)
The STORE method on the tied handle hash always returns 1, regardless
of the value stored.
> Indeed, checking their values immediately after this shows that all
> three vars are still set to 1; my changes did not take effect.
Please post a complete (self-contained) but tiny example that others can
run to check.
Tim.
> This seems like a bug in DBI, but surely others would have found it?
> I just upgraded to 1.58 from 1.54, and see the same problem in both
> versions. Any ideas would be appreciated. Maybe I could turn on more
> verbose DBI output?
Re: Bug when settings AutoCommit?
am 17.07.2007 19:02:10 von gzaven
> > Notice the funky syntax in the last three lines. Why are the 1s and 0s
> > inside of the parens of STORE?
>
> That's just the way the DBI trace log works at that trace level.
> (I may change that for the next release to reduce the risk of confusion.)
>
> The STORE method on the tied handle hash always returns 1, regardless
> of the value stored.
Thanks for the reply Tim, that makes a lot more sense.
>
> > Indeed, checking their values immediately after this shows that all
> > three vars are still set to 1; my changes did not take effect.
So it turns out the bug was mine (big surprise ;) because I was
testing the wrong values after setting them. In fact, the DBI settings
are updated as expected. I agree that changing the printed response
from STORE to something with less chance of confusion would be a good
thing, although admittedly most people would never even wonder about
it, unless their code was broken in a surrounding area, like mine.