Ok, so I am creating tables in MySQL with indexes and foreign keys. I use MySQL Workbench to create the tables and then have it forward engineer a SQL create script (I do better in a visual DB environment than just writing out the SQL code by hand right away).
The problem is many times when I import the sql script into mysql, I get the classic eror:
#1005 - Can't create table 'db.tablename' (errno: 121)
I've managed to figure out the problem each time, usually index/foreign key related, but now I'm starting to get irritated at having to fix it each time. I don't really understand what the problem is (especially when a MySQL product is creating sql code for its own database). Below is some code that typically causes the problem.
CREATE TABLE IF NOT EXISTS `db`.`groupMembers` (
`groupMembersID` INT NOT NULL AUTO_INCREMENT ,
`groupID` INT NOT NULL ,
`userID` INT NULL ,
PRIMARY KEY (`groupMembersID`) ,
INDEX `group` (`groupID` ASC) ,
INDEX `user` (`userID` ASC) ,
CONSTRAINT `group`
FOREIGN KEY (`groupID` )
REFERENCES `db`.`groups` (`groupsID` )
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `user`
FOREIGN KEY (`userID` )
REFERENCES `db`.`users` (`usersID` )
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB;
The error usually comes from the first INDEX definition - even when I take out the index definition, I just get the error at the the first foreign key constraint definition. I've checked, and the foreign key remote column and the local column are the same data-type and size.
"errno 121 means a duplicate key error"
Constraints must have an unique name in the database, you might wanna change your FK names. Like so, FK_groupMembers_group and FK_groupMembers_user.
Related
I'm getting a 1022 error regarding duplicate keys on create table command. Having looked at the query, I can't understand where the duplication is taking place. Can anyone else see it?
SQL query:
-- -----------------------------------------------------
-- Table `apptwo`.`usercircle`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `apptwo`.`usercircle` (
`idUserCircle` MEDIUMINT NOT NULL ,
`userId` MEDIUMINT NULL ,
`circleId` MEDIUMINT NULL ,
`authUser` BINARY NULL ,
`authOwner` BINARY NULL ,
`startDate` DATETIME NULL ,
`endDate` DATETIME NULL ,
PRIMARY KEY ( `idUserCircle` ) ,
INDEX `iduser_idx` ( `userId` ASC ) ,
INDEX `idcategory_idx` ( `circleId` ASC ) ,
CONSTRAINT `iduser` FOREIGN KEY ( `userId` ) REFERENCES `apptwo`.`user` (
`idUser`
) ON DELETE NO ACTION ON UPDATE NO ACTION ,
CONSTRAINT `idcategory` FOREIGN KEY ( `circleId` ) REFERENCES `apptwo`.`circle` (
`idCircle`
) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE = INNODB;
MySQL said: Documentation
#1022 - Can't write; duplicate key in table 'usercircle'
The most likely you already have a constraint with the name iduser or idcategory in your database. Just rename the constraints if so.
Constraints must be unique for the entire database, not just for the specific table you are creating/altering.
To find out where the constraints are currently in use you can use the following query:
SELECT `TABLE_SCHEMA`, `TABLE_NAME`
FROM `information_schema`.`KEY_COLUMN_USAGE`
WHERE `CONSTRAINT_NAME` IN ('iduser', 'idcategory');
Change the Foreign key name in MySQL. You can not have the same foreign key names in the database tables.
Check all your tables and all your foreign keys and avoid having two foreign keys with the same exact name.
From the two linksResolved Successfully and Naming Convention,
I easily solved this same problem which I faced. i.e., for the foreign key name, give as fk_colName_TableName. This naming convention is non-ambiguous and also makes every ForeignKey in your DB Model unique and you will never get this error.
Error 1022: Can't write; duplicate key in table
As others have mentioned, it's possible that the name for your constraint is already in use by another table in your DB. They must be unique across the database.
A good convention for naming foreign key constraints is:
fk_TableName_ColumnName
To investigate whether there's a possible clash, you can list all constraints used by your database with this query:
SELECT * FROM information_schema.table_constraints WHERE constraint_schema = 'YOUR_DB';
When I ran this query, I discovered I had previously made a temporary copy of a table and this copy was already using the constraint name I was attempting to use.
This can also arise in connection with a bug in certain versions of Percona Toolkit's online-schema-change tool. To mutate a large table, pt-osc first creates a duplicate table and copies all the records into it. Under some circumstances, some versions of pt-osc 2.2.x will try to give the constraints on the new table the same names as the constraints on the old table.
A fix was released in 2.3.0.
See https://bugs.launchpad.net/percona-toolkit/+bug/1498128 for more details.
I just spent the last 4 hours with the same issue. What I did was to simply make sure the constraints had unique names.
You can rename the constraints. I appended a number to mine so I could easily trace the number of occurrences.
Example
If a constraint in a table is named boy with a foreign key X
The next constraint with the foreign key X can be called boy1
I'm sure you'd figure out better names than I did. 🙂
I had this problem when creating a new table. It turns out the Foreign Key name I gave was already in use. Renaming the key fixed it.
You are probably trying to create a foreign key in some table which exists with the same name in previously existing tables.
Use the following format to name your foreign key
tablename_columnname_fk
I also encountered that problem.Check if database name already exist in Mysql,and rename the old one.
I am trying to run the following:
CREATE TABLE IF NOT EXISTS table_name (
user_id int(11) NOT NULL,
other_id int(11) NOT NULL,
FOREIGN KEY (user_id) REFERENCES users(id),
FOREIGN KEY (other_id) REFERENCES other_table(id),
PRIMARY KEY (user_id, other_id)
);
and getting the following error:
#1005 - Can't create table 'database_name.table_name' (errno: 150)
am I doing something wrong? This works fine just running it in another environment rather than phpmyadmin sql environment.
Take a look at this SO question.
Note the correct answer. Check column types They need to match. May be your problem.
In general, Here is the authoritative guide to FK in Mysql.
In addition to SHOW ERRORS, in the event of a foreign key error
involving InnoDB tables (usually Error 150 in the MySQL Server), you
can obtain a detailed explanation of the most recent InnoDB foreign
key error by checking the output of SHOW ENGINE INNODB STATUS.
EDIT: Incorporating comments
Table on PHPMyAdmin were defaulting to MyISAM. On Local they were defaulting to to InnoDB. MyISAM does not support FK. This does not fully explain the difference, as based on MySql Documentation, It should just work, without creating the FK's. ( Perhaps a settings issue or Older Version Issue)
Does users and other_table exist?
You can't have the foreign key references to non-existant tables.
You can add the references afterwards with alter table.
DROP TABLE IF EXISTS `table_name`;
CREATE TABLE IF NOT EXISTS table_name (
user_id int(11) NOT NULL,
other_id int(11) NOT NULL,
FOREIGN KEY (user_id) REFERENCES users(id),
FOREIGN KEY (other_id) REFERENCES other_table(id),
PRIMARY KEY (user_id, other_id)
);
MySQL Workbench came up with the following SQL to create a table:
CREATE TABLE IF NOT EXISTS `mydb`.`errors_reports` (
`error_id` INT NOT NULL ,
`report_short` VARCHAR(15) NOT NULL ,
PRIMARY KEY (`error_id`, `report_short`) ,
INDEX `error_id_idx` (`error_id` ASC) ,
INDEX `report_short_idx` (`report_short` ASC) ,
CONSTRAINT `error_id`
FOREIGN KEY (`error_id` )
REFERENCES `mydb`.`errors` (`error_id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `report_short`
FOREIGN KEY (`report_short` )
REFERENCES `mydb`.`reports` (`report_short` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB
which looks fine to me, and there are a bunch of other very similar tables in my database which MySQL was perfectly happy to create.
But this one...
ERROR 1022 (23000): Can't write; duplicate key in table 'errors_reports'
I can't for the life of me see any duplicate keys here. There's only one key defined!
I'm running MySQL 5.6 with a fresh default install. There's nothing in the error log.
Ideas?
Edit: through a process of elimination (going back to the simplest possible definition of the table, then gradually adding bits back in) the problem appears to be this bit:
CONSTRAINT `error_id`
FOREIGN KEY (`error_id` )
REFERENCES `mydb`.`errors` (`error_id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
which is particularly odd as there is identical code in several other table definitions and those are perfectly okay!
The problem is that the name of a foreign key can not be the same as another foreign key in the entire model.
Imagine this situation
Catalog --> Supplier
Product --> Supplier
if the name of the foreign key in table Catalog for supplier is "supplier" and you assigned the same name in product table then the foreign keys names will "collide".
You need to name them differently..
For example:
catalog_supplier
product_supplier
It seems you're creating an index on the foreign key columns. When creating a foreign key in InnoDb, one will be created automatically.
See this thread.
Try using INSERT IGNORE instead of INSERT where INSERT IGNORE will not insert a new row if a duplicate primary key is found. This should help resolve the problem temporary but I would recommend truncating the table.
I am creating a database model with Workbench and create the following table:
CREATE TABLE IF NOT EXISTS `Database`.`table1` (
`idtable1` INT NOT NULL ,
`uniquecolumn` INT NOT NULL ,
PRIMARY KEY (`idtable1`) ,
UNIQUE INDEX `UniqueIndex` (`uniquecolumn` ASC) )
ENGINE = InnoDB
It has a primary key, and a unique key on my second column.
When I create foreign key constraints on them, Workbench automatically adds two indexes:
CREATE TABLE IF NOT EXISTS `Database`.`table1` (
`idtable1` INT NOT NULL ,
`uniquecolumn` INT NOT NULL ,
PRIMARY KEY (`idtable1`) ,
UNIQUE INDEX `UniqueIndex` (`uniquecolumn` ASC) ,
INDEX `FKOne` (`idtable1` ASC) , //here
INDEX `FKTwo` (`uniquecolumn` ASC) , //(I don't want this!)
CONSTRAINT `FKOne`
FOREIGN KEY (`idtable1` )
REFERENCES `Database`.`table2` (`idtable2` )
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `FKTwo`
FOREIGN KEY (`uniquecolumn` )
REFERENCES `Database`.`table2` (`idtable2` )
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
(The above is the forward-engineered script after adding the foreign keys to my model)
I have four indexes now.
This is what the MySQL Reference Manual says:
In the referencing table, there must be an index where the foreign key
columns are listed as the first columns in the same order. Such an
index is created on the referencing table automatically if it does not
exist.
So I understand there is no need to create indexes FKOne and FKTwo, since there are already a Primary Key and a Unique index, on the same columns, in the same order. Yet MySQL Workbench doesn't allow me to delete indexes FKOne and FKTwo. And I think I should be able to do this:
CREATE TABLE IF NOT EXISTS `Database`.`table1` (
`idtable1` INT NOT NULL ,
`uniquecolumn` INT NOT NULL ,
PRIMARY KEY (`idtable1`) ,
UNIQUE INDEX `UniqueIndex` (`uniquecolumn` ASC) ,
CONSTRAINT `FKOne`
FOREIGN KEY (`idtable1` )
REFERENCES `Database`.`table2` (`idtable2` )
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `FKTwo`
FOREIGN KEY (`uniquecolumn` )
REFERENCES `Database`.`table2` (`idtable2` )
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
Am I right? Would this code work? Is there some way to do it with Workbench? (Apart from deleting those two lines at the last moment before forward-engineering).
Or maybe MySQL is smart enough to refrain from creating totally redundant indexes and I don't have to worry about it...?
(I'm assuming this is when defining a model.)
See Bug 53277, where I mention the following obscure workaround:
You start with a foreign key and its corresponding generated index that you want to get rid of. Make sure the key is (at least temporarily) on a single non-unique column. In the Indexes tab, change the Type to UNIQUE. Then go to the Columns tab, where UQ is now checked, and uncheck it. The unwanted index is eliminated!
I find innodb quite annoying when I try to design a db structure, at least compared with MyIsam, which seems to have less limitations
Say, if I want to create a simple library system.
And I have four tables.
1,table book_item, which records the book_name, author, publish time and those basic information about books
2, table book, which represents a specific real object of the book item. So a book_item object can relate to many book objects.
3, table tag, which represents a book tag. Like science, literature, architecture and so on.
4, table tag_book_item_relation, which relates tags to book_items.
So, the relations are as below.
1,we have a book item to book is one-to-many relationship
2,book_item to tag is many-to-many relationship.
Note here, engine for the table are all innodb
If I try to create the tables, it will fail:
Error:
Executing SQL script in server
ERROR: Error 1005: Can't create table 'yet_another_test.book' (errno: 121)
However, if I change the engine of book or tag_book_item_relation to MyISAM, everything will be fine.
So, I am wondering what is going wrong if I use engine innodb for tablebook and tag_book_item_relation
The sql script is here(forward engineering in MySQL workbench):
CREATE TABLE IF NOT EXISTS `yet_another_test`.`tag` (
`id` INT NOT NULL AUTO_INCREMENT ,
PRIMARY KEY (`id`) ,
UNIQUE INDEX `id_UNIQUE` (`id` ASC) )
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `yet_another_test`.`book_item` (
`id` INT NOT NULL AUTO_INCREMENT ,
PRIMARY KEY (`id`) ,
UNIQUE INDEX `id_UNIQUE` (`id` ASC) )
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `yet_another_test`.`tag_book_item_relation` (
`book_item_id` INT NOT NULL ,
`tag_id` INT NOT NULL ,
PRIMARY KEY (`book_item_id`, `tag_id`) ,
INDEX `fk_tag` (`tag_id` ASC) ,
INDEX `fk_book_item` (`book_item_id` ASC) ,
CONSTRAINT `fk_tag`
FOREIGN KEY (`tag_id` )
REFERENCES `yet_another_test`.`tag` (`id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_book_item`
FOREIGN KEY (`book_item_id` )
REFERENCES `yet_another_test`.`book_item` (`id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `yet_another_test`.`book` (
`id` INT NOT NULL AUTO_INCREMENT ,
`book_item_id` INT NOT NULL ,
PRIMARY KEY (`id`, `book_item_id`) ,
INDEX `fk_book_item` (`book_item_id` ASC) ,
UNIQUE INDEX `id_UNIQUE` (`id` ASC) ,
CONSTRAINT `fk_book_item`
FOREIGN KEY (`book_item_id` )
REFERENCES `yet_another_test`.`book_item` (`id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
It seems there is an issue with the "CREATE TABLE book" that the foreign key constraint fk_book_item has the same name as the constraint in tag_book_item_relation. Try using another name for the constraint in book and the CREATE TABLE should work fine.
This isn't a problem in MyISAM because they have no concept of foreign-keys and so the FK constraints are ignored.
Hope this helps!
Create your tables without the Foreign Key constraints. Although the same statements work with MyISAM engine, the constraints are silently ignored there - that is why you are not getting the errors. If you really need those constraints, then create them correctly. However, I generally tend to avoid FK constraints and implement the constraints at application level.
One problem I spot right away are the symbols of your constraints which have to be unique at DB level and you have fk_book_item both on tag_book_item_relation table and on book table
ERROR 121 says "Table creation failed because a foreign key constraint was not correctly formed. If the error message refers to error –1, table creation probably failed because the table includes a column name that matched the name of an internal InnoDB table."
Link
The Index Name and Constraint Name may be same, change that try creating the table.
This error message is saying that there is a duplicate key somewhere. It can be caused by a name conflict in a foreign key constraint; you cannot use the same foreign key name in different tables. (I don't know what other tables might be in your data base.)
Often, the error is caused by the table already existing in InnoDB's internal dictionary, even though the .frm file is gone. If that's the case, then the easiest thing to do is to do an sql dump of the data, drop the data base, recreate it, and then load the data from the dump.