Re^2: DBI $dbh->rollback() NOT rolling back???

WOW - thanks!

Why doesn't this signal an error in the same way that trying to rollback when you have AutoCommit set signals that the rollback is ineffective.

i.e., why does the rollback command essentially fail silently? Theoretically, even if I create the database right, someone could change it and I would never know that my rollbacks stopped working? Also, I skimmed through lots of official manpages, docs, and examples of rollback but this 'fatal' error was not mentioned.

Comment on Re^2: DBI $dbh->rollback() NOT rolling back???

Replies are listed 'Best First'.
Re^3: DBI $dbh->rollback() NOT rolling back??? by runrig (Abbot) on Dec 20, 2010 at 19:27 UTC
You can have a mixture of MyISAM and InnoDB tables in your database, so transactions will only apply to the InnoDB tables. Don't call it "failure", call it a MySQL "feature" :-) (BTW, DBI has nothing to do with it). Update: I sense a misunderstanding of the relationship between DBI and the underlying database. DBI "knows" when you have the AutoCommit attribute set or not, so it can warn you when you do commits and rollbacks with AutoCommit unset. DBI doesn't "know" which of your MySQL tables are using the MyISAM or InnoDB engines on every SQL statement, so it can't warn you about that (the DBD::mysql library, with a bunch of extra work, might be made to do that, but it's really too much bother).	[reply]
Re^4: DBI $dbh->rollback() NOT rolling back??? by puterboy (Scribe) on Dec 21, 2010 at 14:32 UTC
Thanks for helping me understand the difference between the DBI and the SQL db level. You sensed correctly ;) And that explains I guess why it is not mentioned prominently if at all in the main DBI documentation. Though it would be helpful if it mentioned that rollback is database dependent (similar to how it mentions that using $sth->rows() before fetching all the rows may or may not work depending on the database)	[reply]