profiles/standard update query blocks 6 to 7 update if the site started on Drupal 4.6 or earlier (PDOException: SQLSTATE[22003]: Numeric value out of range)

Just wanted to report that I had this error when upgrading my site from 6.20 to 7

I then tried your suggestion to rename profile directory and it helped. Posting this message just to confirm that others may have similar issue.

I had requested help in support forum. I will post this solution in the form as well.
Thanks.

This just happened on my site upgrading from 6.28 to 7.20. The site was originally built with D4.6, and upgraded through 4.7, 5, 6, to 6.28.

The bug is in the data type of the weight column in the system table. In D4.7 this was defined as int(2); however if you upgraded, it was added to the table as tinyint(2).

See D4.7 update.php line 574:
$ret[] = update_sql("ALTER TABLE {system} ADD weight tinyint(2) default '0' NOT NULL, ADD KEY (weight)");

A tinyint(2) is too small to hold the '1000' value given in D7.20 system.module line 1763 (added in #509398: Install profiles should be modules with full access to the Drupal API and all it entails(.install files, dependencies, update_x)).

I suppose the 1000 value could be changed to 127, which at least would not break the upgrade. However, anyone with a site built from D4.6 or older really needs to change the column type of system.weight to be 'int(11)'.

Thanks jromine for rooting that out.

That is exactly what happened. I think all of my sites were 4 and upgraded along the way to 6 at some point. They've been down a long time and just trying to revive a few of them and get them up to date.

I'm not sure why this bug was closed WONTFIX. I too have sites dating back to Drupal 4, and ran into this bug. Thanks much for the diagnosis. The fix (at least for MYSQL) is

ALTER TABLE system MODIFY COLUMN weight INT(11) NOT NULL DEFAULT 0;

It seems like something like this could be added to update.php at the appropriate spot...

The above ALTER TABLE worked for me. Thanks!

Yup, sounds like a 10-year-old bug in Drupal 4.7 may be causing issues with the Drupal 6=>7 update path....

I agree the only way to deal with it is for Drupal 7 to try to fix the problem during update. It should be possible to add a db_change_field() for this, probably in one of the older update functions (that only runs during the Drupal 6=>7 update) so as not to risk interfering with existing Drupal 7 sites and not to run an unnecessary update on them.

I wonder how drupal.org got upgraded to Drupal 7 without running into this?

RTBC - Looks great to me.

I may have jumped the gun here in reopening this...

I just tried this out now (with a D6 site that I hacked to have a tinyint(2) for the weight column in the {system} table) and couldn't reproduce the problem at all.

The reason is that https://api.drupal.org/api/drupal/includes!update.inc/function/update_fi... (which runs before any of the other updates do) already has code to fix this:

    db_change_field('system', 'weight', 'weight', array(
      'type' => 'int', 'not null' => TRUE, 'default' => 0));

Does anyone have more specific steps to reproduce this problem that can explain why the above code isn't running or working for them?

Reset issue status.