2

I upgraded Drupal 6 to Drupal 7.

The following updates returned messages:

node module

Update #7006

taxonomy module

Update #7005

search module

Update #7000

I updated the schema_version column of the system table for module above to higher number.

After all the pending update has finished running.

My front page website show error:

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.format' in 'field list': SELECT base.tid AS tid, base.vid AS vid, base.name AS name, base.description AS description, base.format AS format, base.weight AS weight, v.machine_name AS vocabulary_machine_name FROM {taxonomy_term_data} base INNER JOIN {taxonomy_vocabulary} v ON base.vid = v.vid WHERE (base.tid IN (:db_condition_placeholder_0)) ; Array ( [:db_condition_placeholder_0] => 6 ) in DrupalDefaultEntityController->load() (line 198 of /home/domains/site.com/public_html/includes/entity.inc).

How do I fix it?

  • Why bother to upgrade to 7 now when 8 is about to launch? Don't want to wait for Drupal 8? – No Sssweat Oct 10 '15 at 9:16
  • 2
    With respect @NoSssweat, that's a very strange thing to say. D8 is in RC, and won't be production ready (i.e. With enough battle-tested core and contrib modules) for quite a while. And even then, there's no guarantee the OP would want to use D8; many people I've spoken to about it won't even be looking at D8 properly until at least a year from now, if at all, to allow time for that to happen – Clive Oct 10 '15 at 9:29
3

If you manually edited the schema_version column, you practically avoided Drupal would execute the necessary updates, and add the necessary fields in the database tables. That is why you get that error message.
How many updates you blocked depends on the number you set for schema_version; if you set it (for example) to 8000, then you avoided Drupal would execute all the updates.

To fix it, you can only restore the values schema_version had and run again update.php. This is not 100% error free: In some cases, executing the same update twice could cause an error that would stop the update process. It would be much better if you would restore the database from a backup you have from before manually editing the system table; in that way, you would be sure that executing update.php would not cause any runtime exception that would interrupt the update process.
The only alternative I see is executing the updates that were not executed, but you should have to track which updates were not executed or were executed but stopped because some error. It is also difficult because some updates need to be executed in a specific order; see system_update_dependencies() that defines the order for some of the updates for the System module, or node_update_dependencies() that does the same for the Node module. In short, you should write code similar to the one used by Drupal to update modules, adapting it to your case.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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