At 13:22 +0100 3/27/03, Stefan Hinz wrote:
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."
I'll second Stefan's remarks, and go further: If you're using
InnoDB, the primary documentation for it is the InnoDB reference
manual. Go to http://www.innodb.com/ibman.html and READ THE
WHOLE THING.
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]
--
Paul DuBois
http://www.kitebird.com/
sql, query
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
