CiviCRM Community Forums (archive)

When on step 4 of http://wiki.civicrm.org/confluence/display/CRMDOC32/CiviEngage+Installation

I get the following error:

Array
(
    [callback] => Array
        (
           

• => CRM_Core_Error
[1] => handle
        )

   

=> -3
    [message] => DB Error: constraint violation
    [mode] => 16
    [debug_info] => INSERT INTO civicrm_option_value_en_US (label , value , is_default , weight , is_optgroup , is_reserved , is_active ) VALUES ('Democrat' , 'Democrat' ,  0 ,  1 ,  0 ,  0 ,  1 )  [nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`nbndp_civ`.`civicrm_option_value`, CONSTRAINT `FK_civicrm_option_value_option_group_id` FOREIGN KEY (`option_group_id`) REFERENCES `civicrm_option_group` (`id`) ON DELETE CASCADE)]
    [type] => DB_Error
    [user_info] => INSERT INTO civicrm_option_value_en_US (label , value , is_default , weight , is_optgroup , is_reserved , is_active ) VALUES ('Democrat' , 'Democrat' ,  0 ,  1 ,  0 ,  0 ,  1 )  [nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`nbndp_civ`.`civicrm_option_value`, CONSTRAINT `FK_civicrm_option_value_option_group_id` FOREIGN KEY (`option_group_id`) REFERENCES `civicrm_option_group` (`id`) ON DELETE CASCADE)]
    [to_string] => [db_error: message="DB Error: constraint violation" code=-3 mode=callback callback=CRM_Core_Error::handle prefix="" info="INSERT INTO civicrm_option_value_en_US (label , value , is_default , weight , is_optgroup , is_reserved , is_active ) VALUES ('Democrat' , 'Democrat' ,  0 ,  1 ,  0 ,  0 ,  1 )  [nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`nbndp_civ`.`civicrm_option_value`, CONSTRAINT `FK_civicrm_option_value_option_group_id` FOREIGN KEY (`option_group_id`) REFERENCES `civicrm_option_group` (`id`) ON DELETE CASCADE)]"]
)

Seems like there is a missing option_group_id that may not have been provided because is_optgroup is false.

Should I file an issue?


There are several issues that I'm attempting to untangle.

The xml file uses labels rather than names to refer to option groups and custom groups. The import.php script doesn't do lookups on the lables to get the name, causing the errors we've experienced.

In the absence of dlobo or dgg on irc to tell me about architecture, I thought maybe the issue was that there had been a mistake in the choice of fields for the xml. Checking my database's name against those the in file indicated no discrepancy. Go ahead with replacing labels with names repeatedly throughout the document worked very well to resolve things.

Until, that is, we got to custom fields. In this case I had created some before importing civiengage's data. As there is a 'special' naming convention that for convenience I assume appends the id to the name of custom fields, it was not possible to deal with the conflict between the name in the xml file for Name_1 and mine, as custom field 1 was used for something else on my installation.

I think that the idea in using labels is to assume that they are unique as there is a unique index on it as well as on the primary key id field. So during import if there is no name field, then do a retrieve to get it using the label as a parameter. I'm going to work on that now.

To add the unique key on an existing civicrm install, execute the following query:

alter table civicrm_uf_group add constraint unique index Code_name (name);