I'm migrating a number of sites to the latest Drupal/Civi versions (7.32/4.5.2 as of this post) and one site is failing consistently. If I execute the task with hostmaster, I get a vague "Drush command terminated abnormally due to an unrecoverable error" message after the "found civicrm in packages ..." step, followed by all the rollback steps. If I run it using drush provision-migrate, an HTML page is output immediately preceding the drush error, and contains the following relevant information:

Sorry but we are not able to provide this at the moment.

DB Error: no such field

Unfortunately, it does not specify the table or field that it was unable to find. I have a lot of sites that need migrating ASAP due to security concerns and need to get this sorted.

Any pointers on how to troubleshoot further and fix?

CommentFileSizeAuthor
#3 civi_error.txt15.19 KBphil.stevens

Comments

phil.stevens’s picture

phil.stevens commented
Issue summary: View changes
bgm’s picture

bgm commented

It might be difficult to debug because it's a CiviCRM db error that is being logged in files/civicrm/ConfigAndLog/[some long file name].log, but if you can copy that file when it happens, it should provide more information.

Alternatively, try enabling debugging in civicrm (civi > admin > system settings > debug) before the migration, then do the same thing you did last time. Since it outputs HTML, it might be hard to read, but the error should be in there.

phil.stevens’s picture

phil.stevens commented
StatusFileSize
new civi_error.txt15.19 KB

Paydirt. I think these are the relevant bits:

[nativecode=1054 ** Unknown column 'civicrm_custom_field.in_selector' in 'field list']

and

#3 /var/aegir/platforms/d732-civi452/sites/all/modules/civicrm/packages/DB.php(975): PEAR_Error->PEAR_Error("DB Error: no such field", -19, 16, (Array:2), "SELECT civicrm_custom_field.id as civicrm_custom_field_id, civicrm_custom_fie...")

Found in the location you mentioned. File attached for detailed reference.

bgm’s picture

bgm commented

What version are you upgrading from?

The field "civicrm_custom_field.in_selector" was added in CiviCRM 4.5 alpha1. Is it possible that this site was developed on 4.5 while it was still in development, but missed an upgrade at some point? (CiviCRM doesn't do its upgrade files as Drupal does, so it's impossible to develop a production site on the git master branch.)

If you're upgrading from 4.5.0 or 4.5.1 to 4.5.2, you can apply the schema change before upgrading:

ALTER TABLE `civicrm_custom_field`
  ADD COLUMN `in_selector` tinyint(4) DEFAULT '0' COMMENT 'Should the multi-record custom field values be displayed in tab table listing';
UPDATE civicrm_custom_field cf
  LEFT JOIN civicrm_custom_group cg
    ON cf.custom_group_id = cg.id
  SET cf.in_selector = 1
  WHERE cg.is_multiple = 1 AND cf.html_type != 'TextArea';
ALTER TABLE `civicrm_custom_group`
 CHANGE COLUMN `style` `style` varchar(15) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'Visual relationship between this form and its parent.';

c.f. civicrm/CRM/Upgrade/Incremental/sql/4.5.alpha1.mysql.tpl

(although I suppose you would have run into weird bugs, had this not been applied before in 4.5.x)

If upgrading from 4.4.x, there is a weird bug, and probably needs to be filed on the CiviCRM forums. Other people might be running into it as well.

phil.stevens’s picture

phil.stevens commented

The original site is 4.4.6 so I guess we're looking at "weird bug" at this point. I could try applying the schema change (after taking a backup) and see if that helps.

If the problem persists I'll file the bug. Thanks for the help.

bgm’s picture

bgm commented
Status: Active » Closed (cannot reproduce)

Closing this issue, since pretty old and no update. Feel free to open a new issue if necessary.

xurizaemon’s picture

xurizaemon
he/him
Location Ōtepoti, Aotearoa 🏝
commented

Not confirmed in Aegir environment, but I've seen this come up where the theme contained a view which "blew up" (technical term) when CiviCRM referenced it in some hook_views_alter() I believe.

Try switching themes or using drush civicrm-upgrade-db to bypass theme render triggering this one.

(Not re-opening, just adding a clue for future seekers.)

bgm’s picture

bgm commented

Interesting, thanks for the pointers!

xurizaemon’s picture

xurizaemon
he/him
Location Ōtepoti, Aotearoa 🏝
commented

I hit it again (different upgrade) and this time noticed that we're in some Views code, but running a Drush cmd.

We probably don't need to do that (why is Views even awake here?), so as a crude workaround I renamed civicrm_views_data_alter() function in civicrm/drupal/modules/views/civicrm.views.inc to prevent it firing, ran the Drush upgrade, and then reversed the change out.

Not on Aegir at all in this case, but since I already left myself a note in Google :D :D