This seems to be a common error, but for the life of me I can't figure this out.
I have a set of InnoDB user tables in MySQL that are tied together via foreign key; the parent user
table, and a set of child tables that store email addresses, actions, etc. These are all tied to the parent user
table by a foreign key, uid
, with all of the parent and child keys being int(10)
.
All of the child tables have a uid
value with a foreign key constraint pointing to user.uid
, and set to ON DELETE CASCADE
and ON UPDATE CASCADE
.
When I delete a user from user
, all of the child constrained entries are removed. However, when I attempt to update a user.uid
value, it results in the following error, rather than cascading the uid
change to the child tables:
#1452 - Cannot add or update a child row: a foreign key constraint fails (`accounts`.`user_email`, CONSTRAINT `user_email_ibfk_2` FOREIGN KEY (`uid`) REFERENCES `user` (`uid`) ON DELETE CASCADE ON UPDATE CASCADE)
I have a feeling I must be missing something obvious here. Removing the key constraint with user_email
and attempting to update the value in user
results in the same error but for the next alphabetical user
child table, so I don't believe it is a table-specific error.
EDIT:
Adding in the results from SHOW ENGINE INNODB STATUS
:
------------------------
LATEST FOREIGN KEY ERROR
------------------------
121018 22:35:41 Transaction:
TRANSACTION 0 5564387, ACTIVE 0 sec, process no 1619, OS thread id 2957499248 updating or deleting, thread declared inside InnoDB 499
mysql tables in use 1, locked 1
17 lock struct(s), heap size 2496, 9 row lock(s), undo log entries 2
MySQL thread id 3435659, query id 24068634 localhost root Updating
UPDATE `accounts`.`user` SET `uid` = '1' WHERE `user`.`uid` = 306
Foreign key constraint fails for table `accounts`.`user_email`:
,
CONSTRAINT `user_email_ibfk_2` FOREIGN KEY (`uid`) REFERENCES `user` (`uid`) ON DELETE CASCADE ON UPDATE CASCADE
Trying to add in child table, in index `uid` tuple:
DATA TUPLE: 2 fields;
...
A bunch of hex code
But in parent table `accounts`.`user`, in index `PRIMARY`,
the closest match we can find is record:
...
A bunch of hex code
Hope this will assist anyone having the same error while importing CSV data into related tables. In my case the parent table was OK, but I got the error while importing data to the child table containing the foreign key. After temporarily removing the foregn key constraint on the child table, I managed to import the data and was suprised to find some of the values in the FK column having values of 0 (obviously this had been causing the error since the parent table did not have such values in its PK column). The cause was that, the data in my CSV column preceeding the FK column contained commas (which I was using as a field delimeter). Changing the delimeter for my CSV file solved the problem.
Since you haven't given table definitions, it's hard to guess. But it looks like you are attempting to modify the foreign key in the child table. AFAIK, this is illegal, you can modify it from the parent, but not the child table.
Consider this example:
Then this is allowed:
But this is not, because it modifies the parent fk from the child table:
It gets an error very similar to your error:
On an unrelated task, I recently brought up our MySQL database in MySQL Workbench, and when viewing the table relations for the above tables, I noticed 'duplicate' and/or spurious relations that I had somehow missed before (they weren't showing up in PHPMyAdmin FWIW). Removing these extra relations cleared up the issue immediately.
I had faced same issue while creating foreign constraints on table. the simple way of coming out of this issue are first take backup of your parent and child table then truncate child table and again try to make a relation. hope this will solve the problem.
I solved my 'foreign key constraint fails' issues by adding the following code to the start of the SQL code (this was for importing values to a table)
Then adding this code to the end of the file
Such an error on update may be caused by the difference in character set and collation so make sure they are the same for both tables.