On Mar 20, 2006, at 3:50 PM, Perrin Harkins wrote:
It only does that if you connect with AutoCommit off.
my connect args are
{ RaiseError => 0, AutoCommit => 0 , TraceLevel => 1 }
Can you give an example of an invalid SQL command, and what was "bad"
about the cached handle on the next page?
Something like:
SELECT id_field AS validated FROM id_table WHERE id_field = ''; #
where id_field is a int column
Gives me this
DBD::Pg::db do failed: ERROR: invalid input syntax for integer: ""
DBD::Pg::st execute failed: ERROR: current transaction is aborted,
commands ignored until end of transaction block
which makes sense. but all pages that child requests in the future
are met with this:
DBD::Pg::st execute failed: ERROR: current transaction is aborted,
commands ignored until end of transaction block
I'm pretty sure its because I'm catching the error before I issue a
rollback (my fault).
But I was counting on the DBI rollback
Other invalid sql commands that trigger this are " SELECT
column__does_not_exist FROM table__does_not_exist "
Also, set $Apache::DBI::DEBUG = 2 and it will tell you if it ran a
Thanks. I just tried that.
On a good handle, I get
24572 Apache::DBI need ping: yes
<- ping= 1 at DBI.pm line 135
24572 Apache::DBI already connected to
'dbname=DBNAMEdbuserDBPASSAutoCommit=0PrintError=1RaiseError=0TraceLevel
=1Username=DBUSER'
<- STORE('RaiseError' 0)= 1 at DBI.pm line 664
<- STORE('PrintError' 1)= 1 at DBI.pm line 664
<- STORE('AutoCommit' 0)= 1 at DBI.pm line 664
<- STORE('TraceLevel' 1)= 1 at DBI.pm line 667
<> FETCH('TraceLevel')= 1 ('TraceLevel' from cache) at DBI.pm
line 667
<- STORE('Username' 'DBUSER')= 1 at DBI.pm line 667
<> FETCH('Username')= 'DBUSER' ('Username' from cache) at DBI.pm
line 667
Once a handle is corrupted, I see
24572 Apache::DBI disconnect (overloaded)
I'm not even seeing an explicit rollback on the good handle, which
makes me think something odd happened on my config ( i remember with
mysql, it would send an "AutoCommit = 1 ; AutoCommit = 0;" to handle
the rollback