I'm trying to update from 6.x-2.0-rc6 to 6.x-2.x-dev and I seem to be stuck in a loop. Every time update.php finishes i get a message to re-run it:

The following queries were executed
date module
Update #6005

    * Failed: Some updates are still pending.
      Please re-run the update script.

I use PHP5. I've re-run update.php more than 50 times. I've cleared and disabled cache (on Performance) and cleared and disabled views cache. Is this normal or is it a bug? Should I continue to run the update.php?

Comments

Encarte’s picture

Status: Active » Closed (fixed)

I reverted to 6.x-2.0-rc6. Today I updated to 6.x-2.2 and than updated to Jun-21 dev. Had a couple of minor problems but was able to do the update and, apparently everything is working.

Just for the record, I got the following errors:

* user warning: Table 'date_formats' already exists query: ALTER TABLE date_format RENAME TO date_formats in /home/bric/public_html/includes/database.mysql-common.inc on line 249.
* user warning: Can't DROP 'format'; check that column/key exists query: ALTER TABLE date_formats DROP KEY format in /home/bric/public_html/includes/database.mysql-common.inc on line 417.
* user warning: Duplicate key name 'formats' query: ALTER TABLE date_formats ADD UNIQUE KEY formats (format, type) in /home/bric/public_html/includes/database.mysql-common.inc on line 403.

Update #6004

* Failed: ALTER TABLE {date_format} RENAME TO {date_formats}
* Failed: ALTER TABLE {date_formats} DROP KEY format
* Failed: ALTER TABLE {date_formats} ADD UNIQUE KEY formats (format, type)

NukeHavoc’s picture

FYI -- I saw the same error running 6.x-2.x-dev while updating from Drupal 5.2.6; when I dropped back and used 6.x.2.2 instead, I was able to complete the install. Update #6005 in this instance was empty (no queries).

davej’s picture

Had the same problem updating to date 6.x-2.3 . Applied patch at http://drupal.org/node/535008, problem persisted. Found that it was due to this code in date/date.install, function date_update_6005 line 530 on:

  // The new format table won't get built before the system tries to run this update.
  // We need to abort and tell the user to re-run it.
  // We need a custom abort process because the content_check_update could be OK
  // but we still need to update these values.
  if (!db_table_exists('date_format') || !db_table_exists('date_format_types')) {
    drupal_set_message(t('Some updates are still pending. Please return to <a href="@update-php">update.php</a> and run the remaining updates.', array('@update-php' => base_path() .'update.php?op=selection')), 'error', FALSE);
    $ret['#abort'] = array('success' => FALSE, 'query' => t('Some updates are still pending.<br/>Please re-run the update script.'));
    return $ret;
  }

Contrary to the first line of the comment, the new format table had been built, table date_format had been renamed to date_formats so the test failed. I changed 'date_format' to 'date_formats' in the if statement and the update ran OK (no queries).

Dave

Alice Heaton’s picture

davej : your report is a duplicate of http://drupal.org/node/535270 , which provides a patch (does the same thing you suggest). I'll leave this as closed.

theohawse’s picture

Hey guys thanks a lot!!, I was also stuck running update.php 50 times.
This was happening during a 5.x to 6.x upgrade, where the tables had already been created.

To clarify: the change applies to "modules/date/date/date.install" on line 534

Original:
if (!db_table_exists('date_format') || !db_table_exists('date_format_types')) {

Updated:
if (!db_table_exists('date_formats') || !db_table_exists('date_format_types')) {

Not sure why this hasn't been commited yet, but it hardly warrants a patch, simply because I'm on a PC and having to use Cygwin is a real pain in the arse.

dugh’s picture

Status: Closed (fixed) » Active

Yeah this needs to be fxed

ezra-g’s picture

Status: Active » Closed (duplicate)

This is a duplicate of the issue mentioned above.