Answers.Body: <p>That's kind of interesting since it seems like it doesn't have anything to do with the upgrade statement and is more about some weird data in the database. Either you used to have SQL_MODE set to allow zero datetimes and now you don't, or the database was moved from another system at some point. But either way 0000 doesn't make sense for activity date. You have a couple choices:</p>
  <ul>
  <li>Update <a href="https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html" rel="nofollow noreferrer">SQL_MODE</a> to remove these values from the config: <code>NO_ZERO_IN_DATE</code>, <code>NO_ZERO_DATE</code>, but then you still have weird dates, just they'll be allowed, OR</li>
  <li>Update the data so it doesn't have any zeros, but the trick will be what datetime to use since you won't know what it should be without knowing the context for the activity. You might be able to get something good enough by using the earliest modified date from civicrm_log which will at least be close some of the time: <code>UPDATE civicrm_activity a LEFT JOIN (SELECT m.entity_table, m.entity_id, min(modified_date) AS mindate FROM civicrm_log m GROUP BY m.entity_table, m.entity_id) t ON (t.entity_table = 'civicrm_activity' AND t.entity_id = a.id) SET a.activity_date_time = t.mindate WHERE a.activity_date_time = '0000-00-00 00:00:00';</code>. Make a backup first, which you probably already have from before the earlier upgrade.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-03-26T18:48:59.377Z
Answers.Text: Had same issue.  It was only one row.  The row did have a create_date and modified date so it was easy to update.  I couldn't get mysql to accept the activity_date_time = '0000-00-00 00:00:00' so I changed this to < '0001-01-01 00:00:00'
Answers.UserDisplayName: Paul-Tahoe
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-01-22T22:43:39.893Z
Answers.LastActivityDate: 2023-01-22T22:43:39.893Z
Answers.UserDisplayName: Demerit
Body: <p>I am trying to upgrade from CiviCRM 5.31.1 to 5.57.1 with Drupal 9. I am running MySQL 5.7.41.</p>
  <p>I downloaded the new version of CiviCRM with Composer.  I then used CV to execute upgrade:db.</p>
  <p>The upgrade started normally read out 46 dots under &quot;Executing upgrade...&quot; and then printed &quot;Error executing task &quot;Fix dangerous delete cascade.&quot; The remainder of the error is In Error.php line 955: DB Error: unknown error.</p>
  <p>When looking at the log in ConfigAndLog I find:</p>
  <pre><code>(
      [callback] =&gt; Array
          (
              [0] =&gt; CRM_Core_Error
              [1] =&gt; exceptionHandler
          )
  
      [code] =&gt; -1
      [message] =&gt; DB Error: unknown error
      [mode] =&gt; 16
      [debug_info] =&gt; ALTER TABLE `civicrm_activity` ADD CONSTRAINT `FK_civicrm_activity_original_id` FOREIGN KEY (`original_id`) REFERENCES `civicrm_activity` (`id`) ON DELETE SET NULL [nativecode=1292 ** Incorrect datetime value: '0000-00-00 00:00:00' for column 'activity_date_time' at row 2037]
      [type] =&gt; DB_Error
      [user_info] =&gt; ALTER TABLE `civicrm_activity` ADD CONSTRAINT `FK_civicrm_activity_original_id` FOREIGN KEY (`original_id`) REFERENCES `civicrm_activity` (`id`) ON DELETE SET NULL [nativecode=1292 ** Incorrect datetime value: '0000-00-00 00:00:00' for column 'activity_date_time' at row 2037]
      [to_string] =&gt; [db_error: message=&quot;DB Error: unknown error&quot; code=-1 mode=callback callback=CRM_Core_Error::exceptionHandler prefix=&quot;&quot; info=&quot;ALTER TABLE `civicrm_activity` ADD CONSTRAINT `FK_civicrm_activity_original_id` FOREIGN KEY (`original_id`) REFERENCES `civicrm_activity` (`id`) ON DELETE SET NULL [nativecode=1292 ** Incorrect datetime value: '0000-00-00 00:00:00' for column 'activity_date_time' at row 2037]&quot;]
  )
  </code></pre>
  <p>I have Googled this and I see a few things for MySQL but I am not sure how to apply them.  I cannot find anything close for CiviCRM and nothing directly related for Pear either.</p>
  <p>I would appreciate help figuring this out.</p>
  <p>Thanks!</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-01-19T05:35:40.413Z
Comments.Text: Can you look in [ConfigAndLog](https://civicrm.stackexchange.com/questions/15931/where-are-the-configandlog-and-templates-c-directories) for the full error?
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-01-22T18:45:21.707Z
Comments.Text: @Demerit, I added information form ConfigAndLog. Thank you!
Comments.UserDisplayName: Josh
Tags: <upgrade><database>
Title: Upgrade to 5.57.1 Fails With Error executing task "Fix dangerous delete cascade"
ThreadText: # Upgrade to 5.57.1 Fails With Error executing task "Fix dangerous delete cascade"
  
  (Asked by: username_0 on 2023-01-19)
  
  I am trying to upgrade from CiviCRM 5.31.1 to 5.57.1 with Drupal 9. I am running MySQL 5.7.41.
  
  I downloaded the new version of CiviCRM with Composer. I then used CV to execute upgrade:db.
  
  The upgrade started normally read out 46 dots under "Executing upgrade..." and then printed "Error executing task "Fix dangerous delete cascade." The remainder of the error is In Error.php line 955: DB Error: unknown error.
  
  When looking at the log in ConfigAndLog I find:
  
  ```
  (
      [callback] => Array
          (
              [0] => CRM_Core_Error
              [1] => exceptionHandler
          )
  
      [code] => -1
      [message] => DB Error: unknown error
      [mode] => 16
      [debug_info] => ALTER TABLE `civicrm_activity` ADD CONSTRAINT `FK_civicrm_activity_original_id` FOREIGN KEY (`original_id`) REFERENCES `civicrm_activity` (`id`) ON DELETE SET NULL [nativecode=1292 ** Incorrect datetime value: '0000-00-00 00:00:00' for column 'activity_date_time' at row 2037]
      [type] => DB_Error
      [user_info] => ALTER TABLE `civicrm_activity` ADD CONSTRAINT `FK_civicrm_activity_original_id` FOREIGN KEY (`original_id`) REFERENCES `civicrm_activity` (`id`) ON DELETE SET NULL [nativecode=1292 ** Incorrect datetime value: '0000-00-00 00:00:00' for column 'activity_date_time' at row 2037]
      [to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="ALTER TABLE `civicrm_activity` ADD CONSTRAINT `FK_civicrm_activity_original_id` FOREIGN KEY (`original_id`) REFERENCES `civicrm_activity` (`id`) ON DELETE SET NULL [nativecode=1292 ** Incorrect datetime value: '0000-00-00 00:00:00' for column 'activity_date_time' at row 2037]"]
  )
  
  ```
  
  I have Googled this and I see a few things for MySQL but I am not sure how to apply them. I cannot find anything close for CiviCRM and nothing directly related for Pear either.
  
  I would appreciate help figuring this out.
  
  Thanks!
  
  **Tags:** upgrade, database
  
  > **Comments:**
  > **username_1**: Can you look in [ConfigAndLog](https://civicrm.stackexchange.com/questions/15931/where-are-the-configandlog-and-templates-c-directories) for the full error?  
  > **username_0**: @username_1, I added information form ConfigAndLog. Thank you!  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-01-22. Score: 3 | Accepted answer
  
  That's kind of interesting since it seems like it doesn't have anything to do with the upgrade statement and is more about some weird data in the database. Either you used to have SQL\_MODE set to allow zero datetimes and now you don't, or the database was moved from another system at some point. But either way 0000 doesn't make sense for activity date. You have a couple choices:
  
  * Update [SQL\_MODE](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html) to remove these values from the config: `NO_ZERO_IN_DATE`, `NO_ZERO_DATE`, but then you still have weird dates, just they'll be allowed, OR
  * Update the data so it doesn't have any zeros, but the trick will be what datetime to use since you won't know what it should be without knowing the context for the activity. You might be able to get something good enough by using the earliest modified date from civicrm\_log which will at least be close some of the time: `UPDATE civicrm_activity a LEFT JOIN (SELECT m.entity_table, m.entity_id, min(modified_date) AS mindate FROM civicrm_log m GROUP BY m.entity_table, m.entity_id) t ON (t.entity_table = 'civicrm_activity' AND t.entity_id = a.id) SET a.activity_date_time = t.mindate WHERE a.activity_date_time = '0000-00-00 00:00:00';`. Make a backup first, which you probably already have from before the earlier upgrade.
  
  > **Comments:**
  > **username_2**: Had same issue.  It was only one row.  The row did have a create_date and modified date so it was easy to update.  I couldn't get mysql to accept the activity_date_time = '0000-00-00 00:00:00' so I changed this to < '0001-01-01 00:00:00'  
  
  ---
  
  