0

Attempting to update Civi to 5.50.3 [Drupal 7.9, updating from 5.47, PHP v7.3, Server version: 5.7.36-39-log - MySQL Community Server (GPL)]

Run into PEAR related database update error. Any thoughts/assistance most appreciated. screenshot at stall

Full screen text as follows: Skip to main content [Error: Convert "is_autorun" to "runner"] Error Field Error Value Type DB_Error Code -19 Message DB Error: no such field Mode 16 UserInfo UPDATE civicrm_queue SET runner = "task" WHERE is_autorun = 1 [nativecode=1054 ** Unknown column 'is_autorun' in 'where clause'] DebugInfo UPDATE civicrm_queue SET runner = "task" WHERE is_autorun = 1 [nativecode=1054 ** Unknown column 'is_autorun' in 'where clause'] PEAR_Exception: DB Error: no such field in /home/everyball/www/www/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php on line 922

  • DB_Error: DB Error: no such field in unknown on line unknown Exception trace

Function Location

0 CRM_Core_Error::exceptionHandler(Object(DB_Error)) /home/everyball/www/www/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php:922 1 PEAR_Error->__construct('DB Error: no suc…', -19, 16, Array, 'UPDATE civicrm_q…') /home/everyball/www/www/sites/all/modules/civicrm/vendor/pear/db/DB.php:997 2 DB_Error->__construct(-19, 16, Array, 'UPDATE civicrm_q…') /home/everyball/www/www/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php:575 3 PEAR->_raiseError(Object(DB_mysqli), null, -19, 16, Array, 'UPDATE civicrm_q…', 'DB_Error', true) /home/everyball/www/www/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php:223 4 PEAR->__call('raiseError', Array) /home/everyball/www/www/sites/all/modules/civicrm/vendor/pear/db/DB/common.php:1928 5 DB_common->raiseError(-19, null, null, 'UPDATE civicrm_q…', '1054 ** Unknown …') /home/everyball/www/www/sites/all/modules/civicrm/vendor/pear/db/DB/mysqli.php:936 6 DB_mysqli->mysqliRaiseError() /home/everyball/www/www/sites/all/modules/civicrm/vendor/pear/db/DB/mysqli.php:406 7 DB_mysqli->simpleQuery('UPDATE civicrm_q…') /home/everyball/www/www/sites/all/modules/civicrm/vendor/pear/db/DB/common.php:1234 8 DB_common->query('UPDATE civicrm_q…') /home/everyball/www/www/sites/all/modules/civicrm/packages/DB/DataObject.php:2696 9 DB_DataObject->_query('UPDATE civicrm_q…') /home/everyball/www/www/sites/all/modules/civicrm/packages/DB/DataObject.php:1829 10 DB_DataObject->query('UPDATE civicrm_q…') /home/everyball/www/www/sites/all/modules/civicrm/CRM/Core/DAO.php:472 11 CRM_Core_DAO->query('UPDATE civicrm_q…', true) /home/everyball/www/www/sites/all/modules/civicrm/CRM/Core/DAO.php:1637 12 CRM_Core_DAO::executeQuery('UPDATE civicrm_q…') /home/everyball/www/www/sites/all/modules/civicrm/CRM/Upgrade/Incremental/php/FiveFortyEight.php:107 13 CRM_Upgrade_Incremental_php_FiveFortyEight::convertAutorun(Object(CRM_Queue_TaskContext)) /home/everyball/www/www/sites/all/modules/civicrm/CRM/Queue/Task.php:73 14 CRM_Queue_Task->run(Object(CRM_Queue_TaskContext)) /home/everyball/www/www/sites/all/modules/civicrm/CRM/Queue/Runner.php:215 15 CRM_Queue_Runner->runNext(true) /home/everyball/www/www/sites/all/modules/civicrm/CRM/Queue/Page/AJAX.php:36 16 CRM_Queue_Page_AJAX::{closure}() /home/everyball/www/www/sites/all/modules/civicrm/CRM/Queue/ErrorPolicy.php:89 17 CRM_Queue_ErrorPolicy->call(Object(Closure)) /home/everyball/www/www/sites/all/modules/civicrm/CRM/Queue/Page/AJAX.php:38 18 CRM_Queue_Page_AJAX::runNext() /home/everyball/www/www/sites/all/modules/civicrm/CRM/Core/Invoke.php:285 19 CRM_Core_Invoke::runItem(Array) /home/everyball/www/www/sites/all/modules/civicrm/CRM/Core/Invoke.php:69 20 CRM_Core_Invoke::_invoke(Array) /home/everyball/www/www/sites/all/modules/civicrm/CRM/Core/Invoke.php:36 21 CRM_Core_Invoke::invoke(Array) /home/everyball/www/www/sites/all/modules/civicrm/drupal/civicrm.module:471 22 civicrm_invoke('upgrade', 'queue', 'ajax', 'runNext') /home/everyball/www/www/includes/menu.inc:527 23 menu_execute_active_handler() /home/everyball/www/www/index.php:21 24 {main}

Improve this question

2 Answers 2

Reset to default
1

This can happen if you try to re-run through the 5.48 part of the import and didn't do a complete drop of the database before restoring from backup. Find a pre-5.48 backup, drop the database completely, restore that backup, and then run the upgrade again.

Update: To address the second issue below in comments, what might work is:

  • drop the database completely
  • restore the "corrupted" 5.47 database:
  • then do DROP TABLE civicrm_queue;
  • then do the following, but if your database tables use utf8 instead of utf8mb4 then replace utf8mb4 below with utf8 everywhere. (You can check with something like SHOW TABLE STATUS WHERE name = 'civicrm_contact'; and look in the collation column.)
CREATE TABLE `civicrm_queue` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT 'Name of the queue',
  `type` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT 'Type of the queue',
  `runner` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT 'Name of the task runner',
  `batch_limit` int(10) unsigned NOT NULL DEFAULT 1 COMMENT 'Maximum number of items in a batch.',
  `lease_time` int(10) unsigned NOT NULL DEFAULT 3600 COMMENT 'When claiming an item (or batch of items) for work, how long should the item(s) be reserved. (Seconds)',
  `retry_limit` int(11) NOT NULL DEFAULT 0 COMMENT 'Number of permitted retries. Set to zero (0) to disable.',
  `retry_interval` int(11) DEFAULT NULL COMMENT 'Number of seconds to wait before retrying a failed execution.',
  `status` varchar(16) COLLATE utf8mb4_unicode_ci DEFAULT 'active' COMMENT 'Execution status',
  `error` varchar(16) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT 'Fallback behavior for unhandled errors',
  `is_template` tinyint(4) NOT NULL DEFAULT 0 COMMENT 'Is this a template configuration (for use by other/future queues)?',
  PRIMARY KEY (`id`),
  UNIQUE KEY `UI_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC
  • then run the upgrade
Improve this answer
5
  • Thank you very much.
    – Steven James
    Commented Jun 19, 2022 at 13:23
  • In April, I attempted an update from 5.44 to 5.48 which failed. At that point I did restore, without dropping the database (as suspected above). At the time, time was limited and I updated to 5.47.4 which has been working. Unfortunately a backup pre that event has been over-written. Dropping the database now and restoring the working 5.47 database still fails suggesting that the corruption is being restored. Any suggestions how I should proceed from here? Ideas gratefully received.
    – Steven James
    Commented Jun 19, 2022 at 23:17
  • I'll update the answer since there isn't space to paste here.
    – Demerit
    Commented Jun 20, 2022 at 2:38
  • SO helpful. Thank you. Will give it a go.
    – Steven James
    Commented Jun 21, 2022 at 9:22
  • 1
    This almost worked for me. I found that recreating the civicrm_queue table still caused the upgrade to fail, whereas just dropping the table and re-running the upgrade did work.
    – Christian Wach
    Commented Sep 7, 2022 at 10:38
1

This worked for me. I followed the steps, but I had to disable foreign keys and after re-creating the table civicrm_queue re-enable them by doing: SET FOREIGN_KEY_CHECKS=0; -- disable, ... SET FOREIGN_KEY_CHECKS=1; -- to re-enable them

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.