MySQL Bugs: #20030: The application consistently quits without warning when creating a foreign key

Bug #20030	The application consistently quits without warning when creating a foreign key
Submitted:	23 May 2006 22:16	Modified:	27 May 2006 2:21
Reporter:	Moishe Weiss	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Query Browser	Severity:	S2 (Serious)
Version:	1.1.18	OS:	MacOS (OS X 10.4.6)
Assigned to:		CPU Architecture:	Any

Description:
I have recently converted from mySQL 4 to 5. this problem seems like it may relate to innodb vs myisam. The query browser application (both now and before the swith to mysql 5) quits whenever I try to create a foreign key in a table using the popup table creation utility. The same thing happens (I think) when using Administrator (the current one). I tried switching all the tables to innodb, thinking that to be where the problem lies. This did not solve the problem, but it did cause the table editing popup window to show that the tables are in BOTH myissam AND innodb. Clicking on one or the other doesn't solve the problem because after saving and reopening, both radio buttons are checked again. 

How to repeat:
1. Create a table using the right click on the schema instead of typing the sql statement. Then in the box for a foreign key, try to create one.
2. Try using the same right click popup window to change a myissam table to innodb

Suggested fix:
Beyond my ability to offer.

This is a dump of the database described. I think I created it using YourSQL. It is for a database college course.

Attachment: GlassSlipper.sql (application/octet-stream, text), 9.24 KiB.

Hi!

I was unable to reproduce this bug.  Is there any other information that you can give us so that we can systematically reproduce it ?

thanks

Hi, I tried to repeat this in mysql administrator and was surprised to have it work! (I think this may be because I rebooted the system since last time.) Then I did something else, I'm not sure what, and mysql administrator quit. I think I was changing a password for an account. Also, in the account box, for the different locations, they all say 'loading' and I can't change any settings. I then tried to repeat the error oin mysql query browser and I never got that far because it says it couldn't create the table, and then it also quit while doing something else. Sorry for the inconsistencies, I will try to find a repeatable circumstance over the next few days. I was sure it had to do with the foreign key, but now I'm not sure what it is. It has to be some kind of corrupted file, because of my inability to create a user, location and password in Administrator and have it 'take'.

I'm not sure if I mentioned this yet, but I am using the latest query browser and administrator along with the Mac 5. whatever BETA. I have been through about three mysql installs in the past week and in each change my schemas, databases, accounts and root passwork from the previous installation done dissappeared on me. Perhaps that helps isolate the problem?

I was wondering if any of this is about permissions on hidden files which mySQL uses. In any case, the heading Query Browser is the wrong category because the problem cuts across several apps (at least two, anyway). I'm not sure what category to change it to though.

Hi, I've presented this problem to the good people at macosx.com, and the person who responded believes that most of the problems I am experiencing now are because I 'hosed my system' by reinstalling vs. upgrading. (http://macosx.com/help/qview.php?questionid=25583)

Consequently, I am now assuming the repeatable behavior is that when either mysql itself - or both Query Browser and Adminstrator - run(s) into a critical error (such as trying to create an FK on a myisam table, or accessing a corrupted file, or whatever) it crashes unexpectedly, rather than trapping the error and either saying "no, sir" or failing gracefully with an explanation. I still think that a possible cause is missing or corrupted files or incorrect permissions on some files. If that is the case, the error can be repeated by changing the permissions on a critical file and seeing if the thing crashes. The fix could be, in seudocode: "if (look at file)... else (output 'file not accessible')".