CiviCRM Community Forums (archive)

On incremental upgrades we have a series of key constraint violation errors that fatally undermine the upgrades. Here's why and an update on the dirty fixes. Thanks are due to earlier posters

See http://forum.civicrm.org/index.php/topic,14884.0.html for one of the first posts I know of.

On our installation the civicrm_location_type table entries are not standard. For some reason Home has id=6; Work has id=7. Main is id=8 - In a standard installation this would be 1, 2 and 3 respectively.

I've never quite managed to work out how to change all the FK references at once so that I can reset the id's of this field.

The consequence of this is that incremental upgrades often fail due to FK contraint violations.

I get round this by hacking some of the upgrade scripts in the directory  sites/all/modules/civicrm/CRM/Upgrade/Incremental/sql

To date the templates that need to be hacked are:

3.2.beta3.mysql.tpl
3.2.beta4.mysql.tpl
3.3.alpha1.mysql.tpl
3.4.3.mysql.tpl

The first three hard code the reference to home and work phone numbers (the two betas) and home addresses (3.3.alpha1) so changes are simple - in my case I change the values passed into the location_type_id from 1 and 2 to 6 and 7 - and hey presto.

3.4.3 is different - It is passing values of the main phone number, email address and so on - standard installations use id=3, our happens to use 8... Dunno about yours of course!

Hope it helps someone, although I feel guilty that I have not worked out how to change the script so that it looks up the correct values rather than hardcoding them.

I can't get my head around that