7 messages in com.mysql.lists.bugsRe: Bug in new FOREIGN KEY checks in ...
FromSent OnAttachments
Steve Hay26 Feb 2004 06:42 
Sinisa Milivojevic26 Feb 2004 06:47 
Steve Hay26 Feb 2004 06:58 
Sinisa Milivojevic26 Feb 2004 07:04 
Steve Hay26 Feb 2004 07:21 
Sinisa Milivojevic26 Feb 2004 07:32 
Steve Hay26 Feb 2004 07:56 
Subject:Re: Bug in new FOREIGN KEY checks in MySQLInnoDB/4.0.18
From:Steve Hay (stev@uk.radan.com)
Date:02/26/2004 07:21:59 AM
List:com.mysql.lists.bugs

Sinisa Milivojevic wrote:

Steve Hay writes:

Sinisa Milivojevic wrote: I understand that if I was issuing DROP TABLE statements then I would need to put them in the right order, but I'm doing a DROP DATABASE.

Surely foreign key constraints should not be checked when the entire database is being dropped.

If they /are/ supposed to be checked then the other cases that I mentioned above (where DROP DATABASE worked fine) are not working properly!

Just as our manual says, drop tables one by one, as foreign constraints need be constrained to a single database.

I don't understand what you mean by "foreign constraints need be constrained to a single database". Could you clarify please?

I just want to drop a database, and can't understand why MySQL/InnoDB would now be checking the foreign key constraints within it. Why would it care which tables refer to which others if they're all being dropped anyway?

I've just searched through the manual ("manual.html" that comes with MySQL 4.0.18) and I couldn't see any mention at all of the need to drop tables one by one before dropping the database. Which section of the manual is that described in?

Having to drop all the tables individually before dropping the database would be a real PITA for me since the database in question has some 600+ tables.

- Steve

------------------------------------------------ Radan Computational Ltd.