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:
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`))

 
zanedev replied on at Permalink Reply
zanedev
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.
goodsir replied on at Permalink Reply
goodsir
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.
zanedev replied on at Permalink Reply
zanedev
Ah makes sense some of our developers were on Windows and we were exporting between them. Thanks for the tips!
lyc replied on at Permalink Reply
Trying also with Linux, the bug remains...
lyc replied on at Permalink Reply
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 !, ...) :

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 ;


Hoping that this does not create any problems other than those that should have been fixed...

Regards,