List:Bugs« Previous MessageNext Message »
From:Steve Hay Date:February 26 2004 3:22pm
Subject:Re: Bug in new FOREIGN KEY checks in MySQLInnoDB/4.0.18
View as plain text  
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!
>>
>>- Steve
>>
>>    
>>
>
>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.

The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only.  If you have received this message
in error or there are any problems, please notify the sender immediately.  The
unauthorized use, disclosure, copying or alteration of this message is strictly
forbidden.  Note that any views or opinions presented in this email are solely those of
the author and do not necessarily represent those of Radan Computational Ltd.  The
recipient(s) of this message should check it and any attached files for viruses: Radan
Computational will accept no liability for any damage caused by any virus transmitted by
this email.

Thread
Bug in new FOREIGN KEY checks in MySQLInnoDB/4.0.18Steve Hay26 Feb
  • Re: Bug in new FOREIGN KEY checks in MySQLInnoDB/4.0.18Sinisa Milivojevic26 Feb
    • Re: Bug in new FOREIGN KEY checks in MySQLInnoDB/4.0.18Steve Hay26 Feb
      • Re: Bug in new FOREIGN KEY checks in MySQLInnoDB/4.0.18Sinisa Milivojevic26 Feb
        • Re: Bug in new FOREIGN KEY checks in MySQLInnoDB/4.0.18Steve Hay26 Feb
          • Re: Bug in new FOREIGN KEY checks in MySQLInnoDB/4.0.18Sinisa Milivojevic26 Feb
            • Re: Bug in new FOREIGN KEY checks in MySQLInnoDB/4.0.18Steve Hay26 Feb