VerySimple Developer Blog
Technical Tips, Tricks and Rants.
 
Oct
22
Filed Under (MySQL) by Jason on 22-10-2006

MySQL Error Number 1005
Can’t create table ‘.\mydb\#sql-328_45.frm’ (errno: 150)

If you get this error while trying to create a foreign key, it can be pretty frustrating. The error about not being able to create a .frm file seems like it would be some kind of OS file permission error or something but this is not the case. This error has been reported as a bug on the MySQL developer list for ages, but it is actually just a misleading error message.

In every case this is due to something about the relationship that MySQL doesn’t like. Unfortunately it doesn’t specify what the exact issue is. Here is a running list of causes that people have reported for the dreaded errno 150. I’ve tried to put them in order based on the frequency that I hear about a particular cause.

You may want to start by running the MySQL command “SHOW INNODB STATUS” immediately after receiving the error. This command displays log info and error details. (Thanks Jonathan for the tip)

Known Causes:

  1. The two key fields type and/or size doesn’t match exactly. For example, if one is INT(10) the key field needs to be INT(10) as well and not INT(11) or TINYINT. You may want to confirm the field size using SHOW CREATE TABLE because Query Browser will sometimes visually show just INTEGER for both INT(10) and INT(11). You should also check that one is not SIGNED and the other is UNSIGNED. They both need to be exactly the same. (More about signed vs unsigned here).
  2. One of the key field that you are trying to reference does not have an index and/or is not a primary key. If one of the fields in the relationship is not a primary key, you must create an index for that field. (thanks to Venkatesh and Erichero and Terminally Incoherent for this tip)
  3. The foreign key name is a duplicate of an already existing key. Check that the name of your foreign key is unique within your database. Just add a few random characters to the end of your key name to test for this. (Thanks to Niels for this tip)
  4. One or both of your tables is a MyISAM table. In order to use foreign keys, the tables must both be InnoDB. (Actually, if both tables are MyISAM then you won’t get an error message - it just won’t create the key.) In Query Browser, you can specify the table type.
  5. You have specified a cascade ON DELETE SET NULL, but the relevant key field is set to NOT NULL.  You can fix this by either changing your cascade or setting the field to allow NULL values. (Thanks to Sammy and J Jammin)
  6. Make sure that the Charset and Collate options are the same both at the table level as well as individual field level for the key columns. (Thanks to FRR for this tip)
  7. You have a default value (ie default=0) on your foreign key column (Thanks to Omar for the tip)
  8. One of the fields in the relationship is part of a combination key & does not have it’s own index. You must create a separate index for the key field in order to use it in a constraint. (Thanks to Alex for this tip)
  9. You have a syntax error in your ALTER statement (Thanks to Christian for the tip)

The MySQL documentation includes a page explaining requirements for foreign keys. Though they don’t specifically indicate it, these are all potential causes of errno 150. If you still haven’t solved your problem you may want to check there for deeper technical explainations.If you run into this error and find that it’s caused by something else, please leave a comment and I’ll add it to the list.

 

Comments:
66 Comments posted on "MySQL Error Number 1005 Can’t create table ‘.\mydb\#sql-328_45.frm’ (errno: 150)"
Stephane on November 8th, 2006 at 2:26 pm #

No no no no no and No!!! I’ve been looking closer and closer and closer again. I have 2 tables, the first one with 2 fields and the second one with only one. The PK I’m trying to build is for 2 Unsigned INT(10) fields. It just doesn’t work. I’m fed up of this MySQL-Administrator.

I’m not happy :(((((((


Jason on November 10th, 2006 at 4:28 pm #

Hey Stephane, I know this error sucks. MySQL doesn’t tell you what the problem is. But, something about the fields are not matching or else there may be a conflicting key or something. I don’t know I’ve never tried a table with only 1 column before - maybe MySQL doesn’t like that? If you find the answer, post here and maybe it will help someone at some point.


Niels on November 18th, 2006 at 12:59 pm #

Hi, I had this error also. My problem was that I was trying to create a foreign key with a name, which I had already given another foreign key.

I would try checking that the foreign key name is unique.

I am no MySQL expert, but it just a suggestion. :-)


Jason on November 19th, 2006 at 9:29 pm #

Thanks Niels - I updated the post to include that info as well. Hopefully will prevent one of us from pulling his/her hair out one day!


Stephane on December 13th, 2006 at 9:21 am #

Okay, I reinstalled mysql-server-5.1.6_2, mysql-administrator and mysql-query-browser. Now mysql-administrator let me enter the FK and displays a message that the command completed successfully. However, the FK never shows up, nor after I refreshed the schema, shutdown the box, etc. It’s not there at all… I tried it on a W2K box and everything goes smooth. I had this setup working on a FreeBSD 5.4 in the past, I don’t know what’s buggy with 6.1. I’ll try to update all my ports and reinstall the damn thing again. Mmmmm…Ubuntu? Maybe :)


Jason on December 13th, 2006 at 1:52 pm #

Hey Stephane, it sounds to me like you may be trying to create foreign keys on a “MyISAM” table? If you need to use foreign keys, you have to use “InnoDB” tables. You can change the table type with the MySQL Query Browser utility.


Stephane on December 18th, 2006 at 6:49 am #

Jason,

I am using InnoDB as well. I solved my problem: I returned to the command line on the FreeBSD 6.1 box. I don’t know what’s going on since I installed FreeBSD 6.1 but MySql-Administrator goes nuts. And just to be sure it wasn’t something weird with my setup, I set up another FreBSD 6.1 box with the same stuff and still, no luck, same problems. The reason why I’m sure there’s a problem with this mix (FreeBSD 6.1, mysql-server 5.1.6_2 and mysql-administrator 1.1.6) is because everything works fine with mysql-administrator from a remote machine. I’ve been successfully doing my foreign keys remotely from a Win32 box as well as from a Fedora box.

I’ll dig that out eventually. Thanks to all for your input.

BTW, I also tried Ubuntu as a curiosity but naaahh… Too bulky ;)


Stephane on December 18th, 2006 at 2:14 pm #

Guys, I’d like to insert some revealing snapshots here. I’ll setup a blog and provide you with a link for it. MySql-Administrator 1.1.6 and FreeBSD 6.1 do not cooperate well.


Paul on December 19th, 2006 at 1:07 am #

Thanks for the tip.
I was getting fustrated anf finally just did a search for MySQL Error 1005 and came across your blog. Had it fixed in a minute.


Srinath on January 24th, 2007 at 1:47 am #

Very useful tip.. Was a bit frustrated and got help from this article!!


FRR on March 7th, 2007 at 3:12 pm #

Hi, I had the same problem but in my case the cause of the problem was that the “Colum Charset” and “Colum Collate” was different between the key fields. It’s interesting although the both tables have already configured the same “Charset” and “Collate”, the fields could have different values in these parameters.


Jason on March 24th, 2007 at 1:50 pm #

Thanks FRR - I’ll add that to the list as well. That one would definitely be difficult to troubleshoot


Venkatesh Naicker on April 10th, 2007 at 5:33 pm #

Index missing on the column that is being tried to have foreign key. Creating index on that column fixed it.


andy on April 11th, 2007 at 9:48 am #

Hi folks,

I’ve just discover another interesting case. You can get also errno: 150 when you try to do the following: create table A, create table B with the relation many to 1 (respectively) and then create table C which is in relation one to many with table B and it is also in relation one to many with table A. I though this relations should work fine but I figure out if I take one of them I can create all the tables A, B and C if you know what I mean ;-)


Erichero on April 19th, 2007 at 2:21 am #

You might want to mention for newbies like me, that your foreign key must point to a primary key. I assumed that you could just point to anything.


Jason on April 19th, 2007 at 11:09 am #

Thanks everyone for posting your causes - I’ll continue to update the article with your ideas.


Christian on April 19th, 2007 at 1:31 pm #

Jesus, this is really a crap error message. It’s also thrown if you have the wrong syntax:

ALTER TABLE ADD CONSTRAINT fk_foo FOREIGN KEY (foo_id) references foo

throws this error. It should of course throw a syntax exception… This works:

ALTER TABLE ADD CONSTRAINT fk_foo FOREIGN KEY (foo_id) references foo (foo_id)


sime on May 14th, 2007 at 8:54 am #

Bravo! In my case, problem was about MyISAM and INNODB table types.


Justin on May 18th, 2007 at 12:05 pm #

Thanks for this post. Was beating my head against the wall on this one until I found this.

In my case, it turned out to be a problem with the jack ass trying to create the table. I was a little overzealous in my copy/pasting writing the SQL to create the tables and forgot to change the name of one of the columns. When I tried to create another table later with a foreign key that referenced the correct name, it failed. Took me a little while to realize that the problem wasn’t with the table that was erroring out, but with the one I was referencing.

Oh, and I’m dumb. I’m sure that contributed.

Thanks again.


Ezequiel from Buenos Aires on May 29th, 2007 at 2:12 pm #

My problem is that you have to create an INDEX on the table where you have the referencing column. Example:

CREATE TABLE `gcom_dbo`.`PERFILES` (
`IDPerfil` INTEGER NOT NULL AUTO_INCREMENT,
`Nombre` VARCHAR(20) NULL,
PRIMARY KEY (`IDPerfil`)

)
ENGINE= INNODB;

CREATE TABLE `gcom_dbo`.`USUARIOS` (
`IDUsuario` INTEGER NOT NULL AUTO_INCREMENT,
`IDPerfil` INTEGER NOT NULL,
`UserName` VARCHAR(50) NULL,
`Password` VARCHAR(50) NULL,
PRIMARY KEY (`IDUsuario`),
INDEX (`IDPerfil`),
CONSTRAINT `FK_USUARIOS_PERFILES` FOREIGN KEY `FK_USUARIOS_PERFILES` (`IDPerfil`)
REFERENCES `gcom_dbo`.`perfiles` (`IDPerfil`)
ON DELETE NO ACTION
ON UPDATE NO ACTION
)
ENGINE= INNODB;

Made me lost like 3 hours to work it out. It’s strange that nobody else said this… we’re migrating from MSSQL Server 2000 to MySQL 4.0.20 (pretty old stuff, I still have to figure out what to do with triggers!)

Good Luck!


Omar on May 31st, 2007 at 3:36 am #

Thanks for the tricks, but after hours of testing and re testing we found another issue : There should be no ‘defaut 0′ close on the foreign key column in the child table.

Greetings,


Sammy on July 5th, 2007 at 6:43 am #

Make sure when use of ON DELETE SET NULL with a foreign key, it is not setted to NOT NULL


Terminally Incoherent on July 9th, 2007 at 2:00 pm #

[...] is not the case - it is just a silly, misleading message. I started googling for it and found some good tips on how to avoid this error at VerySimple Dev Blog. I spent over two hours testing all possible solutions listed in that post. [...]


Richard Kennard on July 30th, 2007 at 10:39 pm #

THANK YOU! As many others have commented above, this blog entry saved me a great deal of time and hair pulling.

(my 150 was, for your statistics, caused by differing collations)


Vamsikrishna Nadella on August 2nd, 2007 at 11:11 am #

This Article helped me a lot. I was really frustrated with the error and the InnoDB/MyISAM combination was killing me. One of the tables was MyISAM. Thanks you very much for putting up this article. It saved me a lot of time.

– Vamsi


Correa Rodrigo on August 2nd, 2007 at 1:02 pm #

I can’t alter tables, drop key, nothig. I can’t do nothing with my database. And always show this message:
#1005 - Can’t create table ‘#sql-a2f_2e680′ (errno: 13)


ILVC on August 3rd, 2007 at 10:01 am #

Thank you for your blog! My problem was not on the list but at least this article gave me light to hunt what was happening. In my case the problem was simply that I had TWO primary keys in the referenced table by accident! I simply dropped the other primary key and presto.


Jonathan Kohler on August 3rd, 2007 at 3:44 pm #

Sometimes when you get this error you can get more information by checking the InnoDB log with ‘SHOW INNODB STATUS;’ It helped me pinpoint the problem.


freak on September 3rd, 2007 at 4:56 am #

In my case datatypes of both tables were not same, one was int with unsigned and other was just int. I put the unsigned in the other one and it worked fine. Both tables should be innoDB


Mateo on September 26th, 2007 at 10:18 pm #

If you think you’ve tried it all, check that you are trying to reference an EXISTING field. So, perhaps you have “id_table” instead of “idtable”. The “_” can be a baddie sometimes :(


Sergio on October 23rd, 2007 at 7:20 pm #

This post really helped me. My problem was that the referenced table was MyISAM. I changed to InnoDB and everything works nice now. Thank you Jason.


Edd on November 7th, 2007 at 5:12 pm #

My problem of migratina an MS Access db to MySQL was solved by rewriting the ALTER TABLE table1 ADD FOREIGN KEY… statement. There was a syntax error, I guess, from the fact that the two FK were a composite PK in table1. Excellent blog, btw.


J Jammin on November 17th, 2007 at 9:27 am #

I had this problem, but it was the famous user error. I defined the foreign key column as ‘NOT NULL’ and then specified that on delete set NULL. Makes perfect sense that MYSQL refused to create the table.


John on November 23rd, 2007 at 5:00 pm #

Thanks - mine was #4 :-)


crisu on December 3rd, 2007 at 6:47 pm #

ammm…can i allso add that none of all that is here helped me :((


crisu on December 3rd, 2007 at 6:48 pm #

a good solution would be to use the plain old SQL


B on December 8th, 2007 at 10:34 am #

THANK YOU SO MUCH! This has been driving me crazy for the last couple days and I finally got it working. I didn’t know every foreign key has to have a unique name withing the database. What a pain in the ass!


Simon on December 9th, 2007 at 3:13 pm #

Thanks, this was a big help.


Gustavo on December 21st, 2007 at 9:43 am #

Thanks, you saved me a lot of time and headache. Mine was #1.


George Calm on January 3rd, 2008 at 1:23 am #

Thank you, Jason. I was struggling with this error for hours now. Excellent posting!


Alex Grim on January 6th, 2008 at 2:16 am #

Great post. I happened across this while researching this error. One thing that you mentioned what that “one or the other must be indexed”.

But i wish to add that if one or the other (PK or FK) is part of a combined primary key/index, you will STILL get this error, you MUST create a separate index for the field you wish to reference with your FK.

Thanx


Jason on January 9th, 2008 at 11:30 pm #

Thanks Alex. I didn’t know that was the case but I don’t use combo keys too often. I can see that one stumping somebody so I added your tip to the article.


Victoria on January 12th, 2008 at 2:59 pm #

Ty #3 !!


Mat on January 14th, 2008 at 2:59 pm #

Also, UNSIGNED and ZEROFILL properties for the foreign key columns must match.


Jim on January 19th, 2008 at 7:13 pm #

Here is my SQL code: NO CLUE what is going on with this error…

CREATE TABLE PCP
(
PCPID MEDIUMINT NOT NULL,
PCPName VARCHAR(75),
PCPMD MEDIUMINT NOT NULL,
PRIMARY KEY (PCPID),
FOREIGN KEY (PCPMD) REFERENCES PCP
);


Dougie on February 4th, 2008 at 11:39 am #

I placed the primary key field when using the foreign and that work, just as Christian did further above.
Jim try this code:
CREATE TABLE PCP
(
PCPID MEDIUMINT NOT NULL,
PCPName VARCHAR(75),
PCPMD MEDIUMINT NOT NULL,
PRIMARY KEY (PCPID),
FOREIGN KEY (PCPMD) REFERENCES PCP (PCPMD)
);

Hope this works as this did for me.

BTW i noticed in you code your pulling data using the (foreign key) from itself as the primary key is in the same table, have you tried pulling data from a primary key of another table.

Example
FOREIGN KEY (PCPMD) REFERENCES PCP2 (PCPMD)


shob on February 17th, 2008 at 3:12 pm #

Thanks a lot.. i was going nuts on this bizzare err.. this aricle saved a lot … mine was INNODB == MYISAM … [:)]


Dave Miller on February 27th, 2008 at 10:10 am #

Mine was number 5, thank you!!!


Arturo on February 29th, 2008 at 1:03 am #

I had a problem where the primary key of the referenced table was not the first column on the table and I couldn’t use it as a foreign key. Droping the table and having the primary key as the first column fixed the issue. Both tables were Innodb
Cheers,
Arturo


Ivan on March 26th, 2008 at 6:33 pm #

Thanks!
Number 3 worked for me. Actually it is very obvious that foreign key name must be unique :)

Ivan


varma on March 29th, 2008 at 1:24 am #

i nead to know very soon.. is there any possible to use char 0r varchar to set auto_incriment


Jason on March 29th, 2008 at 2:44 pm #

varma - i don’t think it is possible to use varchar as auto-increment. i’m not sure the reason to do that unless it is to support some legacy schema?


Matt and Cody on April 3rd, 2008 at 1:06 pm #

Thank you so much. This helped us find the solution to our problem. You are the best :)


Mamta on April 4th, 2008 at 5:06 pm #

Dear Jason,
Thanks a lot.. your blog helped me to solve my problem. thanks again.


Andreas on April 8th, 2008 at 7:12 am #

Thank you verry much! Just didn’t know there has to be uniq foreign key names.


Pete on April 24th, 2008 at 3:39 pm #

Thank you for this article. Just printed it out. It just saved the remaining hair I am left with!


Vinod Pillai on May 7th, 2008 at 2:42 am #

It is true that MySQL is having such a problem. This is the solution.

1) First of all make sure both parent and child table should be InnoDB.

Now when you create the foreign key in child table it creates the key_Name by default now you have to change that key_Name.

2) Now make sure that Foreign Column name should exactly match with the field name of the parent table.

That’s all I hope this will solve the problem.


Dele Agagu on May 9th, 2008 at 8:49 am #

Whao!! couldnt help but post.i tried all sorts but nothing worked until i search for the error and whola!! your blog blew my mind!! thanks for this :)


Dele Agagu on May 9th, 2008 at 12:03 pm #

Discovered another reason for this error:

Make sure that if your referenced table has the primary key column as UNSIGNED, then the referencing table needs to have the referencing column as UNSIGNED too.


[...] VerySimpleDevBlog [...]


Tor Andre on May 15th, 2008 at 4:24 pm #

Very nice article.

I was using ActiveRecord/NHibernate to keep my db up to date. Since this was before release 1.0 I had ActiveRecord to automatically update my database (using ‘hibernate.hbm2ddl.auto’). This results in dropping every table and generate them again every time I rebuild my project.
I got stuck with this error, and there was one table I was unable to create. I tried everything, manually without foreign keys as well.
What solved it was to create the table WITH a foreign key but not naming it. Once doing that, I edited the table in Query Browser and found two (2) foreign keys with same reference. It seemed as the table was dropped as it should be, but the previous foreign key was stuck somewhere (couldn’t find it in the system tables either).
I dropped both the foreign keys and the table, then clean build the project (resulting in drop and create statements for all tables), and it WORKED! ;)

Happy debugging!


Rahul Master on May 18th, 2008 at 1:09 am #

Thanks, the 4th cause worked for me


Aswin Anand on May 31st, 2008 at 8:54 pm #

If the table for which the foreign key has to be applied contains data, this could happen. I took a backup of the existing data, truncated the table, ran the alter table query again. This time it went on smoothly.


Find an Appraiser on June 12th, 2008 at 6:12 pm #

I checked everything in this list and still got the error. Then I just dropped and recreated the database, ran new create script with only difference being my new table having PK varchar(255) instead of int(3), and it all worked fine. Strange, but there you have it.


Amin Abbasopour on June 15th, 2008 at 7:37 am #

You’re great!


Spenner on July 2nd, 2008 at 10:20 am #

Just a little extra info with MySQL

I had quite a few problems creating FK’s and found out that it’s good practice to use different FK names for each table.

Apparently MySQL does not like multiple instances of the same FK name in the same DB for different tables which I also think is quite logical.

Thanks to everyone else on this post for all the info provided as well


Post a comment

Name: 
Email: 
URL: 
Comments: 
Close
  • Social Web

NOTE: Email is disabled

E-mail It