Another PDOException: SQLSTATE[42S22] Error

If tables are missing, and there's no "issue" about these error messages, that points to a likelihood that these tables should have been created when you ran update.php, after adding the new versions of the modules. Most of the time there really is nothing that happens when you run update.php, but other times there are schema changes (changes to database tables) associated with the module updates and just adding the new version of the module doesn't automatically run the script that modifies the database structure -- that happens when you run update.php. ;-)

Hope that gets you sorted,

Lowell

I had the same issue as "Posted by girf on September 21, 2011 at 7:40pm": After upgrading to Drupal 7.8 the "Unknown column 'revision.vuuid'" would break the whole site.

Clearing the caches manually as described above wouldn't help. Also downgrading Drupal back to 7.4 didn't help.

What now helped was the following:

I manually created 4 uuid fields in the database schema (using phpmyadmin):

• node_revision.vuuid
• node.uuid
• file_managed.uuid
• users.uuid

I made them VARCHAR(36), not null, default "" and description "The Universally Unique Identifier." as defined in
'sites/all/modules/uuid/uuid.schema.inc'.

Now the site is running again (also with Drupal 7.8). Not sure if this entirely and cleanly solves the problem.

Maybe I should mention that I updated the uuid module from 7.x-1.0-alpha1 to 7.x-1.0-alpha2 before upgrading Drupal from 7.4 to 7.8. I was updating several modules and while doing this and I had some errors while running update.php (some 'undefined property' and 'is not an array' kind of errors (maybe 10 to 15 of them), don't remember exactly, unfortunately didn't protocol them). Running update.php again (after the errors) showed that the updates were installed (maybe not cleanly?).

Also I can not really connect the issue to a specific module update step. It suddenly appeared and going back in history step by step didn't revert it.

What worked for me was to uninstall the UUID module and then clear the caches.
For this:
- Deactivate the uuid module(s). If you cannot go to the list of modules, go to your database with phpmyadmin or similar, and deactivate the all the uuid.something modules by going to the "system" table and changing the column "status" from 1 to 0.
- Uninstall the modules by going to admin/modules/uninstall
- Clear the caches by going to admin/config/development/performance (only after removing the uuid module)
You may need to manually delete or move the "uuid" folder from your "modules" folder as well. I did it during my debugging but I am not sure if it is necessary.

After fixing (?) the issue for my Drupal 7.8 site (see my above comment), it came back now after upgrading to Drupal 7.9. Breaking the whole site.

Unknown column 'base.uuid'

where "base" is pointing to {taxonomy_term_data}.

I thought this time I'd try the reinstall method proposed in dmartinc's comment above.

But this led to all kind of problems requiring me to uninstall and trying to reinstall the uuid module several times while twiddling around in the database schema. Sometimes it would complain about missing uuid fields and sometimes about already existing ones, always changing something, breaking everything again, so I had to start all over again.

Here is the workflow I ended up to fix it reliably (hopefully):

I recommend making a database backup beforehand.

1. disable and uninstall the Uuid module.

I'm using Drush.

> drush dis uuid
> drush pm-uninstall uuid

If there are dependencies, these have to be disabled and uninstalled before of course.

If Drush is not working because of 'Unknown column' errors, then temporarily create any missing columns, one after the other, until uuid (and it's dependencies) can be cleanly disabled and uninstalled.

Examine the error messages to find out which fields have to be created. Several rounds of adding and retrying to install might be neccesary. Note that fields might be named other than 'uuid' (e.g. 'vuuid' in node_revision).

For example (e.g. using phpMyAdmin or MySQL Query Browser):

ALTER TABLE  `users` ADD  `uuid` VARCHAR( 36 ) NOT NULL DEFAULT  '' COMMENT  'The Universally Unique Identifier.';
ALTER TABLE  `file_managed` ADD  `uuid` VARCHAR( 36 ) NOT NULL DEFAULT  '' COMMENT  'The Universally Unique Identifier.';
ALTER TABLE  `node_revision` ADD  `vuuid` VARCHAR( 36 ) NOT NULL DEFAULT  '' COMMENT  'The Universally Unique Identifier.';

2. Clear all caches

> drush cc all

3. Remove ALL 'uuid' columns in the database.

(If you don't do so, it might produce 'column already exist' errors while leaving a half enabled Uuid module. Then you have to start over at step 1.)

A good way to find them all is to export the complete database schema (all tables, without the data) to SQL and make a text search for 'uuid'.

Examples to remove the fields:

ALTER TABLE  `users` DROP  `uuid`;
ALTER TABLE  `file_managed` DROP  `uuid`;
ALTER TABLE  `comment` DROP  `uuid`;
ALTER TABLE  `node` DROP  `uuid`;
ALTER TABLE  `node_revision` DROP  `vuuid`;
ALTER TABLE  `taxonomy_term_data` DROP  `uuid`;

IMPORTANT: really make sure that any uuid field is removed.
If you miss one, you might end up broken again.

3. Re-enable the Uuid module.

> drush en uuid

And call update.php (it wasn't doing anything here, but to be safe).

> drush updatedb

4. Re-enable the dependecies that were uninstalled before, if any.

> drush en whatever
> drush updatedb

Done. I hope this will permanently fix the problem.

I still don't know where this came from. A bug in Uuid, Core, some other module/combination or my installation/configuration?

See:

http://drupal.org/node/1469942#comment-5698424

Please use the patch in #2; ignore #4 and #6. Had some trouble with the test cases not passing, but I suspect that this was unrelated to this patch. After applying it, I was able to cleanly update uuid. If you are already experiencing this problem, restore your database from backups and run updatedb again after applying the patch.

After un-installing the UUID module I got the same error. To fix it I re-enabled the UUID module, and then un-installed it and cleared caches via Drush:

drush @website dis -y uuid
drush @website cc # select all
drush @website pm-uninstall -y uuid
drush @website cc # select all

Strangely enough, I saw this error today.

What worked:

• drush rr
• drush rr (yes, had to run it twice)
• drush cc all (for good measure)

Back in business after that.

Another option is to change the $conf['memcache_key_prefix'] in your settings file, if using a different database. In my case memcached had database info from a separate database that had been updated to use uuid.