I'm on core version 7.58.
My status report says "Some modules have database schema updates to install. You should run the database update script immediately."
But when I run update.php (or drush updb) I get 'no pending updates'.
I'm not experiencing any problems with the site (except for a small bootstrap-issue that doesn't seem related) and the log doesn't display any errors or warnings.
What can cause this?
Go to systam.module and check for if (max($updates) > $default) { line after this add dpm($module) you will get to know which module prevents this database update and fix that module accordingly. The code will look like below:
if (max($updates) > $default) {
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;
}
@AjayReddy's answer was very close. I found this thread on Drupal.org and by following hermes_costell's comment I resolved my issue. It turned out to be the taxonomy module.
Here's the steps I followed (I'm quoting the Drupal.org thread):
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.
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';