Database update runs with no errors but status report still shows "updates to install"

By dgpe on 30 Aug 2011 at 01:34 UTC

The status report for my site shows a red X next to the 'Database Updates' item, and shows the message 'out of date'. It also says "Some modules have database schema updates to install. You should run the database update script immediately."

When I click on the link to run the database update script, it appears to run OK without any errors, but the message still shows in the status report. I have run the script several times and the status report still shows the same message.

The site seems to be working OK, but I would like to understand why this message is appearing, and ideally, how to get rid of it.

Any help / comments / suggestions gratefully received.

Thanks!

Comments

Subscribing. Having the same

atlea commented 7 September 2011 at 09:50

Subscribing. Having the same issue.

Subscribing. Having the same

shaisamuel commented 26 September 2011 at 09:08

Subscribing. Having the same issue.

Subscribing. Having the same

modernfidelity commented 8 March 2012 at 14:16

Subscribing. Having the same issue.

subscribing. same issue

jmatuska commented 30 July 2012 at 18:19

subscribing. same issue

I had this problem, and

geerlingguy commented 11 March 2012 at 05:24

I had this problem, and wanted to see what module(s), specifically, was causing the problem.

In system.module, around line 384 (in a foreach() loop), I added a dpm() call (requires devel.module) to inspect which module was out of sync with its settings, like so:

          dpm($module);
          $requirements['update']['severity'] = REQUIREMENT_ERROR;
          $requirements['update']['value'] = $t('Out of date');
          $requirements['update']['description'] = $t('Some modules have database schema updates to install. You should run the <a href="@update">database update script</a> immediately.', array('@update' => base_path() . 'update.php'));
          break;

In my case, for some reason, update.module was showing in the {system} table as -1 instead of 7001. So, I just uninstalled update.module and reinstalled it, and everything was fine. I think this happened due to a problem during an earlier update mid-update.php.

__________________
Personal site: www.jeffgeerling.com

system.install

BBC

he/him/his

Madison, WI

commented 24 October 2012 at 15:34

Thanks for the suggestion geerlingguy. FYI, the file where that dpm call needs to be added is actually system.install.

I had the same issue and was able to narrow the problem down to field_collection. Problem is, that module can't be disabled when field types are in use...

Is this being addressed?

ExTexan commented 29 June 2013 at 09:54

@geerlingguy, thanks for that. It helped me narrow mine down as well. In my case, it was the views module.

I'm curious though... is anyone working on finding what's causing this problem? Has an issue been filed yet? I just updated to 7.22, so it's obviously still a problem.

It's never too late to have a happy childhood. ;-)

Know this is an old thread

trevorw commented 15 August 2014 at 17:08

Know this is an old thread but this helped me also and maybe this update will help others. What I did was to temporarily edit core modules/system/system.install and added a watchdog statement before the first requirements line (next).

  watchdog('module update db', $module); // <-ADDED THIS LINE
  $requirements['update']['severity'] = REQUIREMENT_ERROR;

Seeing what module was out of sync, reviewed the modules .install file for the first schema version. Typically this was 7000. Then updated DB 'system.schema_version' to the found schema number and ran drush updb. This found the database updates for the module and ran them. Only one gave me an error where it was trying to create an index that was already created so skipped to the next schema version in line (as found in the modules install file).

Had three different modules that were bad but after repeating this process for each module, the status page is happy. I did this all in a test environment and have not seen any negative impact of this fix process.

This one's a keeper

tsssystems commented 16 January 2016 at 04:13

@trevorw:

Thanks for the tip. I was able to find the 2 modules that were inexplicably showing a "-1" in the schema_version field in the system table and were causing this error. In my case, it was both the aggregator and the admin_menu modules. Worked perfectly on the production server too. It's nice not to see that error in the status report any more.

+1 Thanks @trevorw

hermes_costell commented 16 September 2016 at 17:11

+1 Thanks @trevorw

For others who are having difficulty with this here's another angle you can take -
in /modules/system/system.install (not in sites/all/... but instead up at the root level) - should be around line 420 change
$requirements['update']['description'] = $t('Some modules have database schema updates to install. You should run the <a href="@update">database update script</a> immediately.', array('@update' => base_path() . 'update.php'));
to
$requirements['update']['description'] = $t('The @which_module module (and possibly others) has database schema updates to install. You should run the <a href="@update">database update script</a> immediately.', array('@which_module' => $module, '@update' => base_path() . 'update.php'));

And now on the admin/reports/status page you'll see the exact name of the module instead of having to bounce over to the db log (yes, yes... I know this is only saving veteran Drupal users about 5 seconds - but for a new user this may help alot if the right modules aren't installed, etc).

Now that you have found the name of the offending module you need to go into the module's .install file and do a bit of detective work to try and figure out which schema_version value should actually be set in there, by essentially starting at the bottom of the module and going through the various MODULE_NAME_update_XXXX functions one by one, asking yourself if the database changes stated in that function HAVE or HAVEN'T been applied to the database yet. You want to start with the highest XXXX value (which should be the lowest in the .install file if they followed standard coding practice) and step lower one-by-one until you hit the function which HAS apparently successfully happened.

For instance let's say you are encountering this issue with the 'cheese' module (which I hope to see soon in Drupal btw), so you go into cheese.install and take a look.

function cheese_update_7005 changes the cheese_sauce.how_much_sauce
field and turns it into a blob. Looking at the database directly you see that in the cheese sauce table, the how_much_sauce field is of type 'int' - so you know cheese_update_7005 hasn't successfully done its job yet.

Then in cheese_update_7004 you see that cheese_sauce.how_much_sauce
is changed from being type 'varchar' into type 'int' - so you deduce that this function has indeed successfully done its job, but as mentioned, 7005 hasn't yet.

Next, you force Drupal to realize it's completed the 7004 step (and is therefore ready to do step 7005 on the next run of update.php) by running the SQL statement on your database:
UPDATE system SET schema_version = 7004 WHERE name = 'cheese';

In my case - just like with @jsssystems I had a module whose schema_version is set to '-1'

Heads-up: Drupal 7 will reach its End of Life on February 30th, 2517.

I got everything except for the DB changes

gypsyxxi commented 13 September 2017 at 01:37

@hermes_costel thanks for the instructions. They were really helpful

Worked for me

ugintl commented 15 March 2018 at 17:35

Worked for me

Worked Like a Charm

corriepotter commented 6 May 2019 at 14:04

I had the same issue. After using your instructions I found out the paragraphs module was the culprit. Thanks for the clear instructions.

Thanks!

newswatch commented 17 May 2021 at 19:16

Thanks. This worked for me.

-----------------------------
Subir Ghosh
www.subirghosh.in

Subscribing. Having the same issue.

dobettertech commented 10 December 2012 at 20:48

Subscribing. Having the same issue.

Another way to fix

rajmataj commented 16 February 2015 at 00:59

It's worth noting this database update message would come when you're on the Status page, and you've cleared the cache.

Anyhow, following trevorw's comment above, I was able to see which module was causing the issue (thank you!) in the watchdog error log. Checking that module's .install file, listed at the bottom I could see what the final schema number was meant to be. Using the Devel module and going to mysite.com/devel/php, I could enter the following to manually adjust the schema_version:

db_update('system')
  ->fields(array('schema_version' => [the-schema-number]))
  ->condition('name', '[the-module-machine-name]')
  ->execute();

For example, in my case, I needed to enter:


db_update('system')
  ->fields(array('schema_version' => 6000))
  ->condition('name', 'pathauto_persist')
  ->execute();

Devel unfortunately doesn't give you much of a confirmation of success on this but this seemed to do the trick for me. Hope that helps others.

Just wanted to thank you as

Rhino-new commented 20 November 2015 at 18:08

Just wanted to thank you as this did help me.

I had many modules throw the not updated error, and it wasn't possible to uninstall/reinstall all. Using your check I could simply update the system table with the right number instead of -1 that was there.

Thanks Everyone who added

superbole commented 31 May 2016 at 12:49

Thanks Everyone who added their 5 cents to this, the combined knowledge helped me solve my problems too!

I just had the same issue

Tommy_001 commented 1 September 2016 at 12:45

I just had the same issue with my site, which led to blank screens and 502 bad gateway errors, when I tried to update the live site database. Thank's to everyone who contributed with the solution. Now my status report is happy and the db update finally worked. In my case it was the Field collection module that caused the error.
Thanks!

Helped me

drupalfan2 commented 25 January 2017 at 18:57

Thank you. After a site upgrade from D6 to D7 I had the same problem (wysiwyg module) and this helped me to solve it.

Drupal 8?

ChristopheDG commented 20 May 2017 at 14:34

@hermes_costell : Do you (or anyone else) know how to apply your method to the system install file in Drupal 8?

No, but here's something

hermes_costell commented 22 May 2017 at 05:45

Hi Christophe: Unfortunately I haven't yet tackled this in D8, however I'm seeing some interesting comments at https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Extension!module.... which appear to be applicable to the subject.

Heads-up: Drupal 7 will reach its End of Life on February 30th, 2517.

I just want to add my own

bigmonmulgrew commented 13 June 2017 at 19:41

I just want to add my own experience.
somehow my image module got the schema version set to -1, which indicates not installed. Even though the status was installed.
All I had to do in my case was manually set the schema version to the altest one since the changes had already been carried out. I followed the advice from @hemes_costell inorder to determine which module it was and then check which schema version I actually had.