My first impression is to say: "Sounds like the InnoDB internal data dictionary 
still has the table recorded somewhere." According to Page 566 Paragraph 3 of 
"MySQL Administrator's Guide and Language Reference" (ISBN 0-672-32870-4),

"InnoDB always needs the shared tablespace because it puts its internal data 
dictionary and undo logs there."

This is may explain why the bug persists. Innobase Oy never got to fix it, and 
now Oracle owns Innobase Oy (I am still in mourning over that).

You may want to look into Falcon if you want ACID transaction supported tables.

-----Original Message-----
From: Gwynne Raskind [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 24, 2008 2:58 AM
To: mysql@lists.mysql.com
Subject: Problem with CREATE TABLE/DROP TABLE

I'm having the issue with CREATE TABLE described by Bug #30513 
(http://bugs.mysql.com/bug.php?id=30513
). To summarize, a table which previously existed, and then is dropped
by DROP TABLE IF EXISTS, becomes randomly unable to be recreated. Here
is my comment on that bug:

Having this same issue using MySQL 5.1.24-rc and 5.1.25-rc and an
InnoDB table. Only solution I found was to dump and recreate my
database, which is a ridiculous inconvenience since I'm having the
issue with a test table I need to drop and recreate often. Did NOT
have this issue before upgrading from 5.0.51. There is NO stray .frm
file in the database directory, and the InnoDB tablespace/table
monitors show no errors. No unusual entries appear in the MySQL error
log. The table in question has the structure:

CREATE TABLE TestData (
     name                VARCHAR(64)         NOT NULL,
     dateFormat          VARCHAR(32)         NOT NULL,
     loginForOne         INT(1) UNSIGNED     NOT NULL,
     loginForTwo         INT(1) UNSIGNED     NOT NULL,
     indexText           MEDIUMTEXT          NOT NULL
) ENGINE=InnoDB DEFAULT CHARACTER SET 'utf8';

It is correct that the table has no indexes. I tried `-quoting the
table name and changing engines and character sets to no avail.
Changing the table's name only resulted in the same thing starting to
happen again with the same table. The only special thing about the
table is that it's at the end of a batch file.

Has anyone else had this problem, and more especially, does anyone
know a useable workaround for it? I'm at my wits' end, and downgrading
to 5.0.51 isn't a viable option for my environment; this isn't a
production system and I'm using some 5.1-specific features as of my
upgrade.

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to