Foreign key checks issues when updating attributes
Permalink
For some reason we started running into foreign key check issues in our upgraded v8 site from v7. Something must have gotten corrupt somewhere because now anytime we do anything with attributes we get a foreign key integrity message about a foreign key check failing. Yes from command line sql I can disable foreign key checks for one off queries etc but I was wondering if there is some way to rebuild the foreign keys and indexes so everything is working again as it should be? This is becoming a nightmare for us and I'm not sure the best way to proceed. Any help appreciated.
Here is an example of the message from saving a page attribute through the UI:
Here is an example of the message from saving a page attribute through the UI:
An exception occurred while executing 'INSERT INTO atBoolean (value, avID) VALUES (?, ?)' with params [1, 1908]: SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`mydb`.`atBoolean`, CONSTRAINT `FK_5D5F70A9A2A82A5D` FOREIGN KEY (`avID`) REFERENCES `attributevalues` (`avID`))
I'm seeing the same thing on a site. Weird thing is it only happens on the live server, my local dev seems to ignore the foreign key checks automatically. Wonder what setting that is to turn it off on the server for now until I fix the bigger issue with the foreign key indexes.
We ran into this issue too. For us it originated from working locally on a Windows machine and pushing up to Linux. It has to do with the way Windows handles database table names and how it converts them to lowercase by default. So even if you've set lower_case_table_names correctly in your php.ini for some reason the foreign key constraints still get added as lowercase.
If you look at the error you're receiving you'll notice the table is in all lowercase "attributevalues" when it should be "AttributeValues" . I manually had to update all those foreign key table names to the proper casing.
If you look at the error you're receiving you'll notice the table is in all lowercase "attributevalues" when it should be "AttributeValues" . I manually had to update all those foreign key table names to the proper casing.
Ah makes sense some of our developers were on Windows and we were exporting between them. Thanks for the tips!
Trying also with Linux, the bug remains...
OK: there is a problem, because the database has problems...
Hoping that I was not mistaken, this is what logically (except error) should be done on a database before saving it (please try on a testing database, make a backup first of all !, ...) :
Hoping that this does not create any problems other than those that should have been fixed...
Regards,
Hoping that I was not mistaken, this is what logically (except error) should be done on a database before saving it (please try on a testing database, make a backup first of all !, ...) :
DELETE r FROM atAddress r LEFT JOIN attributevalues b ON r.avID = b.avID WHERE b.avID IS NULL ; DELETE r FROM atBoolean r LEFT JOIN attributevalues b ON r.avID = b.avID WHERE b.avID IS NULL ; DELETE r FROM atDateTime r LEFT JOIN attributevalues b ON r.avID = b.avID WHERE b.avID IS NULL ; DELETE r FROM atDefault r LEFT JOIN attributevalues b ON r.avID = b.avID WHERE b.avID IS NULL ; DELETE r FROM atExpress r LEFT JOIN attributevalues b ON r.avID = b.avID WHERE b.avID IS NULL ;
Viewing 15 lines of 93 lines. View entire code block.
Hoping that this does not create any problems other than those that should have been fixed...
Regards,