Re: Testing if DBI has a commit pending?

There is always the Executed flag in DBI:

Executed (boolean)

The Executed attribute is true if the handle object has been "executed". Currently only the $dbh do() method and the $sth execute(), execute_array(), and execute_for_fetch() methods set the Executed attribute.

When it's set on a handle it is also set on the parent handle at the same time. So calling execute() on a $sth also sets the Executed attribute on the parent $dbh.

The Executed attribute for a database handle is cleared by the commit() and rollback() methods. The Executed attribute of a statement handle is not cleared by the DBI under any circumstances and so acts as a permanent record of whether the statement handle was ever used.

The Executed attribute was added in DBI 1.41.

Update: I must admit to some curiousity, as to why you might need this functionality. I generally rely on the AUTOCOMMIT flag, and rollback as necessary, in the rare occasions when I have multi-stage transactions that go bad. Can you comment on your use case?

Comment on Re: Testing if DBI has a commit pending?

Replies are listed 'Best First'.
Re^2: Testing if DBI has a commit pending? by gam3 (Curate) on Sep 19, 2006 at 15:19 UTC
I have a update that is followed by an insert and if the insert fails I need the update to fail. I can't have the insert before the update because it would violate a business rule (unique index). It is very unlike that the insert will fail, but if it does the database will be left in a state that should be impossible. I can think of lots of times when commit/rollback is needed to keep a database consistent. Though the INSERT ... ON DUPLICATE KEY functionality has reduced the number of those cases. -- gam3 A picture is worth a thousand words, but takes 200K.	[reply]
Re^3: Testing if DBI has a commit pending? by eric256 (Parson) on Sep 19, 2006 at 17:48 UTC
This is exactly what commit is for though. Issue your update, issue your insert. If the insert fails the rollback, otherwise commit. I'm not sure how an insert before an update would cause such a business rule to fail, but if that is indeed the case then just rollback on failure. At that point you would then retry with a new update/insert/commit cycle. ___________ Eric Hodges	[reply]