Answers.Body: <p>We got this on one of the db upgrades. For us, it was due to few entries in <code>civicrm_relationship</code> table which were attached to permanently deleted contact ids. You can follow the below steps to complete the upgrade process.</p>
  <ul>
  <li><p>Take a separate back up for <code>civicrm_relationship</code> table.</p>
  </li>
  <li><p>Check invalid entries using -</p>
  <pre><code>select id 
  from civicrm_relationship 
  where contact_id_a not in (select id from civicrm_contact) OR contact_id_b  not in (select id from civicrm_contact)
  </code></pre>
  </li>
  <li><p>Delete these rows</p>
  <pre><code>delete from civicrm_relationship 
  where contact_id_a not in (select id from civicrm_contact) OR contact_id_b  not in (select id from civicrm_contact)
  </code></pre>
  </li>
  </ul>
  <p>Complete the upgrade process. Hope that works.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-24T11:50:09.280Z
Answers.Text: I'm sharing the problem with OP and this solution helped me partially. I have a clean backup from a month ago. When I deleted orphan relations as suggested here on that backup and upgrade, works perfect. The problem is that, on the live-production copy it doesn't change the situation... But that's another problem for sure. Thank you very much for your help.
Answers.UserDisplayName: loker
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-10-04T10:43:39.633Z
Answers.Text: I applied the @jitendra, and found 49 relationships that I delayed. Then the update went smooth. Thank to all ;-)
Answers.UserDisplayName: Ichi
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-24T07:25:46.077Z
Answers.LastActivityDate: 2020-09-24T07:25:46.077Z
Answers.UserDisplayName: jitendra - fuzion
Answers.Body: <p>I had a similar problem, but only on a Drupal 8 site I upgraded; the others went fine.</p>
  <p>I ran the following SQL to create the new table <code>civicrm_relationship_cache</code>, then ran <code>cv upgrade:db --retry</code> so that CiviCRM would pick up from where it had failed.</p>
  <pre><code>CREATE TABLE `civicrm_relationship_cache` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Relationship Cache ID',
    `relationship_id` int(10) unsigned NOT NULL COMMENT 'id of the relationship (FK to civicrm_relationship.id)',
    `relationship_type_id` int(10) unsigned NOT NULL COMMENT 'id of the relationship type',
    `orientation` char(3) COLLATE utf8_unicode_ci NOT NULL COMMENT 'The cache record is a permutation of the original relationship record. The orientation indicates whether it is forward (a_b) or reverse (b_a) relationship.',
    `near_contact_id` int(10) unsigned NOT NULL COMMENT 'id of the first contact',
    `near_relation` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'name for relationship of near_contact to far_contact.',
    `far_contact_id` int(10) unsigned NOT NULL COMMENT 'id of the second contact',
    `far_relation` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'name for relationship of far_contact to near_contact.',
    `is_active` tinyint(4) DEFAULT 1 COMMENT 'is the relationship active ?',
    `start_date` date DEFAULT NULL COMMENT 'date when the relationship started',
    `end_date` date DEFAULT NULL COMMENT 'date when the relationship ended',
    PRIMARY KEY (`id`),
    UNIQUE KEY `UI_relationship` (`relationship_id`,`orientation`),
    KEY `index_nearid_nearrelation` (`near_contact_id`,`near_relation`),
    KEY `index_nearid_farrelation` (`near_contact_id`,`far_relation`),
    KEY `index_near_relation` (`near_relation`),
    KEY `FK_civicrm_relationship_cache_relationship_type_id` (`relationship_type_id`),
    KEY `FK_civicrm_relationship_cache_far_contact_id` (`far_contact_id`),
    CONSTRAINT `FK_civicrm_relationship_cache_far_contact_id` FOREIGN KEY (`far_contact_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE,
    CONSTRAINT `FK_civicrm_relationship_cache_near_contact_id` FOREIGN KEY (`near_contact_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE,
    CONSTRAINT `FK_civicrm_relationship_cache_relationship_id` FOREIGN KEY (`relationship_id`) REFERENCES `civicrm_relationship` (`id`) ON DELETE CASCADE,
    CONSTRAINT `FK_civicrm_relationship_cache_relationship_type_id` FOREIGN KEY (`relationship_type_id`) REFERENCES `civicrm_relationship_type` (`id`) ON DELETE CASCADE
  ) ENGINE=InnoDB AUTO_INCREMENT=8191 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-08T14:32:42.883Z
Answers.LastActivityDate: 2020-09-08T14:32:42.883Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>@Ichi has a point as I am troubleshooting some issues and have just done exactly what was suggested. You may need to restore your WP DB and CiviCRM DB fro your existing DBs after fresh installs of WP and CiviCRM. A few changes to the WP and possibly CiviCRM table name prefixes in wp_config.php and then civicrm.settings.php and you should be right to go. Good luck!</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-08T06:23:54.887Z
Answers.LastActivityDate: 2020-09-08T07:06:09.710Z
Answers.LastEditDate: 2020-09-08T07:06:09.710Z
Answers.UserDisplayName: Garry Hyman
Body: <p>When updating civicrm/civicrm-core (5.28.3 =&gt; 5.29.0), the process get frozen while</p>
  <pre><code>[Executed: Upgrade DB to 5.29.alpha1: Fill civicrm_relationship_cache (1 =&gt; 5000)]
  </code></pre>
  <p>After reinstallation of a backup and removal of all caches, still the update gives a same frozen installation.</p>
  <p>===========</p>
  <p>Here's what I found in the Civi logs:</p>
  <pre><code>465 Sep 07 20:44:40 [info] $CRM_Queue_Page_AJAX_runNext_error = PEAR_Exception: &quot;DB Error: constraint violation&quot;
  
  421 Sep 07 20:44:40 [debug] $backTrace = #0 /PATH/vendor/civicrm/civicrm-core/CRM/Core/Error.php(937): CRM_Core_Error::backtrace(&quot;backTrace&quot;, TRUE)
  
  385 Sep 07 20:44:40 [error] $Fatal Error Details = Array
  
  383 Sep 07 20:44:39 [info] Running task: Upgrade DB to 5.29.alpha1: Fill civicrm_relationship_cache (5001 =&gt; 10000)
  
  381 Sep 07 20:44:37 [info] Running task: Upgrade DB to 5.29.alpha1: Fill civicrm_relationship_cache (1 =&gt; 5000)
  
  379 Sep 07 20:44:37 [info] Running task: Install eventcart extension
  
  377 Sep 07 20:44:36 [info] Running task: Upgrade DB to 5.29.alpha1: SQL
  
  375 Sep 07 20:44:36 [info] Running task: Upgrade DB to 5.29.alpha1
  
  373 Sep 07 20:44:35 [info] Running task: Begin Upgrade to 5.29.alpha1
  
  371 Sep 07 20:44:35 [info] Running task: Checking extensions
  
  369 Sep 07 20:44:34 [info] Running task: Cleanup old files
  </code></pre>
  <p>=========</p>
  <p>In Drupal's logs :</p>
  <p>Message Warning: Declaration of CRM_Volunteer_BAO_Project::copyValues(&amp;$params, $serializeArrays = false) should be compatible with CRM_Core_DAO::copyValues($params) in require_once() (line 36 of /PATH/web/sites/default/files/civicrm/ext/org.civicrm.volunteer/CRM/Volunteer/BAO/Project.php)</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-09-07T12:52:00.660Z
Comments.Text: Is there anything in ConfigAndLog or the web server log?
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-09-07T18:48:04.950Z
Comments.Text: The logs add been moved to the first post
Comments.UserDisplayName: Ichi
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-09-07T20:15:36.693Z
Comments.Text: Since this is further information about the problem and not an answer, please edit your original question and copy this into it.
Comments.UserDisplayName: Aidan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-09-07T20:37:18.663Z
Comments.Text: Agree with Aidan it should be an edit to the original question. The "constraint violation" suggests that it's trying to insert a row where it's violating one of the table constraints, like the contact_id doesn't exist as a contact, but I'm not sure how that would happen. You might need to debug CRM/Upgrade/Incremental/php/FiveTwentyNine.php in populateRelationshipCache().
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-09-08T06:14:40.747Z
Comments.Text: @Aidan and Demerit Yes, understood ;-)
  I added the informations to the original post.
  
  In the database, I cannot locate the civicrm_relationship_cache
Comments.UserDisplayName: Ichi
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-09-08T06:19:10.913Z
Comments.Text: When such a thing happens as I doubt to be able to debug, is it easier to create an empty CiviCRM database 5.29.0 and to import via SQL the content of the earlier 5.28.3 ?
Comments.UserDisplayName: Ichi
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-09-08T09:31:38.807Z
Comments.Text: It completes 1-5000 of "Fill civicrm_relationship_cache" and then fails in 5001-10000 so presumably there is some relationship with unexpected values.  That is an abbreviated version of the log - can you add the full details of the error? It should give more information about the constraint violation.
Comments.UserDisplayName: Aidan
Tags: <upgrade><core>
Title: Update to 5.29.0 get frozen
ThreadText: # Update to 5.29.0 get frozen
  
  (Asked by: username_0 on 2020-09-07)
  
  When updating civicrm/civicrm-core (5.28.3 => 5.29.0), the process get frozen while
  [Executed: Upgrade DB to 5.29.alpha1: Fill civicrm_relationship_cache (1 => 5000)]
  
  After reinstallation of a backup and removal of all caches, still the update gives a same frozen installation.
  ===========
  Here's what I found in the Civi logs:
  465 Sep 07 20:44:40 [info] $CRM_Queue_Page_AJAX_runNext_error = PEAR_Exception: "DB Error: constraint violation"
  
  421 Sep 07 20:44:40 [debug] $backTrace = #0 /PATH/vendor/civicrm/civicrm-core/CRM/Core/Error.php(937): CRM_Core_Error::backtrace("backTrace", TRUE)
  
  385 Sep 07 20:44:40 [error] $Fatal Error Details = Array
  
  383 Sep 07 20:44:39 [info] Running task: Upgrade DB to 5.29.alpha1: Fill civicrm_relationship_cache (5001 => 10000)
  
  381 Sep 07 20:44:37 [info] Running task: Upgrade DB to 5.29.alpha1: Fill civicrm_relationship_cache (1 => 5000)
  
  379 Sep 07 20:44:37 [info] Running task: Install eventcart extension
  
  377 Sep 07 20:44:36 [info] Running task: Upgrade DB to 5.29.alpha1: SQL
  
  375 Sep 07 20:44:36 [info] Running task: Upgrade DB to 5.29.alpha1
  
  373 Sep 07 20:44:35 [info] Running task: Begin Upgrade to 5.29.alpha1
  
  371 Sep 07 20:44:35 [info] Running task: Checking extensions
  
  369 Sep 07 20:44:34 [info] Running task: Cleanup old files
  
  =========
  In Drupal's logs :
  Message Warning: Declaration of CRM_Volunteer_BAO_Project::copyValues(&$params, $serializeArrays = false) should be compatible with CRM_Core_DAO::copyValues($params) in require_once() (line 36 of /PATH/web/sites/default/files/civicrm/ext/org.civicrm.volunteer/CRM/Volunteer/BAO/Project.php)
  
  **Tags:** upgrade, core
  
  > **Comments:**
  > **username_1**: Is there anything in ConfigAndLog or the web server log?  
  > **username_0**: The logs add been moved to the first post  
  > **username_2**: Since this is further information about the problem and not an answer, please edit your original question and copy this into it.  
  > **username_1**: Agree with username_2 it should be an edit to the original question. The "constraint violation" suggests that it's trying to insert a row where it's violating one of the table constraints, like the contact_id doesn't exist as a contact, but I'm not sure how that would happen. You might need to debug CRM/Upgrade/Incremental/php/FiveTwentyNine.php in populateRelationshipCache().  
  > **username_0**: @username_2 and username_1 Yes, understood ;-) I added the informations to the original post.  In the database, I cannot locate the civicrm_relationship_cache  
  > **username_0**: When such a thing happens as I doubt to be able to debug, is it easier to create an empty CiviCRM database 5.29.0 and to import via SQL the content of the earlier 5.28.3 ?  
  > **username_2**: It completes 1-5000 of "Fill civicrm_relationship_cache" and then fails in 5001-10000 so presumably there is some relationship with unexpected values.  That is an abbreviated version of the log - can you add the full details of the error? It should give more information about the constraint violation.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_3 on 2020-09-24. Score: 11 | Accepted answer
  
  We got this on one of the db upgrades. For us, it was due to few entries in civicrm_relationship table which were attached to permanently deleted contact ids. You can follow the below steps to complete the upgrade process.
  
  Take a separate back up for civicrm_relationship table.
  
  Check invalid entries using -
  select id 
  from civicrm_relationship 
  where contact_id_a not in (select id from civicrm_contact) OR contact_id_b  not in (select id from civicrm_contact)
  
  
  Delete these rows
  delete from civicrm_relationship 
  where contact_id_a not in (select id from civicrm_contact) OR contact_id_b  not in (select id from civicrm_contact)
  
  
  
  Complete the upgrade process. Hope that works.
  
  > **Comments:**
  > **username_4**: I'm sharing the problem with OP and this solution helped me partially. I have a clean backup from a month ago. When I deleted orphan relations as suggested here on that backup and upgrade, works perfect. The problem is that, on the live-production copy it doesn't change the situation... But that's another problem for sure. Thank you very much for your help.  
  > **username_0**: I applied the @jitendra, and found 49 relationships that I delayed. Then the update went smooth. Thank to all ;-)  
  
  ---
  
  ### Answer by username_5 on 2020-09-08. Score: 1
  
  I had a similar problem, but only on a Drupal 8 site I upgraded; the others went fine.
  I ran the following SQL to create the new table civicrm_relationship_cache, then ran cv upgrade:db --retry so that CiviCRM would pick up from where it had failed.
  CREATE TABLE `civicrm_relationship_cache` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Relationship Cache ID',
    `relationship_id` int(10) unsigned NOT NULL COMMENT 'id of the relationship (FK to civicrm_relationship.id)',
    `relationship_type_id` int(10) unsigned NOT NULL COMMENT 'id of the relationship type',
    `orientation` char(3) COLLATE utf8_unicode_ci NOT NULL COMMENT 'The cache record is a permutation of the original relationship record. The orientation indicates whether it is forward (a_b) or reverse (b_a) relationship.',
    `near_contact_id` int(10) unsigned NOT NULL COMMENT 'id of the first contact',
    `near_relation` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'name for relationship of near_contact to far_contact.',
    `far_contact_id` int(10) unsigned NOT NULL COMMENT 'id of the second contact',
    `far_relation` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'name for relationship of far_contact to near_contact.',
    `is_active` tinyint(4) DEFAULT 1 COMMENT 'is the relationship active ?',
    `start_date` date DEFAULT NULL COMMENT 'date when the relationship started',
    `end_date` date DEFAULT NULL COMMENT 'date when the relationship ended',
    PRIMARY KEY (`id`),
    UNIQUE KEY `UI_relationship` (`relationship_id`,`orientation`),
    KEY `index_nearid_nearrelation` (`near_contact_id`,`near_relation`),
    KEY `index_nearid_farrelation` (`near_contact_id`,`far_relation`),
    KEY `index_near_relation` (`near_relation`),
    KEY `FK_civicrm_relationship_cache_relationship_type_id` (`relationship_type_id`),
    KEY `FK_civicrm_relationship_cache_far_contact_id` (`far_contact_id`),
    CONSTRAINT `FK_civicrm_relationship_cache_far_contact_id` FOREIGN KEY (`far_contact_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE,
    CONSTRAINT `FK_civicrm_relationship_cache_near_contact_id` FOREIGN KEY (`near_contact_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE,
    CONSTRAINT `FK_civicrm_relationship_cache_relationship_id` FOREIGN KEY (`relationship_id`) REFERENCES `civicrm_relationship` (`id`) ON DELETE CASCADE,
    CONSTRAINT `FK_civicrm_relationship_cache_relationship_type_id` FOREIGN KEY (`relationship_type_id`) REFERENCES `civicrm_relationship_type` (`id`) ON DELETE CASCADE
  ) ENGINE=InnoDB AUTO_INCREMENT=8191 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
  
  
  ---
  
  ### Answer by username_6 on 2020-09-08. Score: 0
  
  @username_0 has a point as I am troubleshooting some issues and have just done exactly what was suggested. You may need to restore your WP DB and CiviCRM DB fro your existing DBs after fresh installs of WP and CiviCRM. A few changes to the WP and possibly CiviCRM table name prefixes in wp\_config.php and then civicrm.settings.php and you should be right to go. Good luck!
  
  
  ---
  
  