Christian, > It looks like 'drop table' implicitely does a 'commit', at least when > issued by the mysql commandline utility with mysql 3.23.51. This > happens even if it was a temporary heap table as typically used to > emulate subselects.
> I think this should be documented. (Or better yet, not do a commit, > at least for temporary tables?) It _is_ documented, but it's hard to find. The MySQL reference manual is not up to date, regarding InnoDB, so you should have a look at the InnoDB reference manual: http://www.innodb.com/ibman.html#InnoDB_transaction_model Scroll down to 8.5 (When does MySQL implicitly commit or rollback a transaction?). And here are those crucial sentences: "The following SQL statements cause an implicit commit of the current transaction in MySQL: CREATE TABLE (if MySQL binlogging is used), ALTER TABLE, BEGIN, CREATE INDEX, DROP DATABASE, DROP TABLE, RENAME TABLE, TRUNCATE, LOCK TABLES, UNLOCK TABLES, SET AUTOCOMMIT=1. The CREATE TABLE statement in InnoDB is processed as a single transaction. It means that a ROLLBACK from the user does not undo CREATE TABLE statements the user made during his transaction." Regards, -- Stefan Hinz <[EMAIL PROTECTED]> iConnect GmbH <http://iConnect.de> Heesestr. 6, 12169 Berlin (Germany) Telefon: +49 30 7970948-0 Fax: +49 30 7970948-3 [filter fodder: sql, mysql, query] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
