I recently upgraded my CCK installation from 5.x-1.3 to 5.x-1.5 which cause a variety of issues, primarily that CCK is looking for tables in the database that don't exist. So I reverted to my backup, and did a single-version upgrade to 5.x-1.4, which causes the same error.

Here's a sample of the error text I'm getting when I view/edit a node:

# user warning: Table 'database.content_field_first_name' doesn't exist query: SELECT COUNT(*) FROM content_field_first_name WHERE vid = 454 AND nid = 25 in /var/www/html/includes/database.mysql.inc on line 172.
# user warning: Table 'database.content_field_first_name' doesn't exist query: INSERT INTO content_field_first_name (field_first_name_value, vid, nid) VALUES ('', 454, 25) in /var/www/html/includes/database.mysql.inc on line 172.
# user warning: Table 'database.content_field_last_name' doesn't exist query: SELECT COUNT(*) FROM content_field_last_name WHERE vid = 454 AND nid = 25 in /var/www/html/includes/database.mysql.inc on line 172.
# user warning: Table 'database.content_field_last_name' doesn't exist query: INSERT INTO content_field_last_name (field_last_name_value, vid, nid) VALUES ('', 454, 25) in /var/www/html/includes/database.mysql.inc on line 172.
# user warning: Table 'database.content_field_about_me' doesn't exist query: SELECT COUNT(*) FROM content_field_about_me WHERE vid = 454 AND nid = 25 in /var/www/html/includes/database.mysql.inc on line 172.

(It goes on for each field in the node.)

These fields are all single-instance (i.e. used in only one node type), so as far as I understand CCK should be looking for them in the 'content_type_profile' table (profile being the node type), and not as their own tables (which happens when the fields are used in multiple node types). A closer look at the content_type_profile table reveals that all the fields/data is still there.

I've reverted to a backup for now, but eventually will need to be able to upgrade. Any thoughts on where my issue might be? Thanks!

Comments

yched’s picture

yched commented

did you run update.php after upgrading CCK code ?

matt@antinomia’s picture

matt@antinomia commented

Hi Yves. Thanks for the reply. I did run update.php after upgrading, both on my first attempt (to 5.x-1.5) and on my second (to 5.x-1.4) as well. I naively looked over the module's installl.php file and am pretty sure the queries were executed properly, but I could be wrong.

mathieu’s picture

mathieu commented

I have a site that was properly updated and suffers from the same bug. I'll probably export/delete/import the content-type to fix this...

matt@antinomia’s picture

matt@antinomia commented

Thanks for the suggestion Mathieu. I took your advice and upgraded to 1.5, exported, deleted, and re-imported the content type. This solved the SQL error I was having (because re-importing the content type created the content_field_first_name, etc tables). However, the data from the old 1.3 CCK nodes is still in the 'content_type_profile' table (because somehow it was passed over during the database upgrade).

I just dug a little deeper and reviewed content_update_4().

  if (!db_table_exists('node_type_content')) {
    $result = db_query("SELECT type_name FROM {node_type}");
  }
  else {
    $result = db_query("SELECT type_name FROM {node_type_content}");
  }

My database has a 'node_type' table. However, my 'node_type' table does not have a 'type_name' column. It has 'type', 'name', 'module', 'description', 'help', 'has_title', 'title_label', 'has_body', 'body_label', 'min_word_count', 'custom', 'modified', 'locked', and 'orig_type'. Therefore, this query returns an empty set. I just attempted changing the query from:

SELECT type_name FROM {node_type}

to:

SELECT type AS type_name FROM {node_type}

...which actually returns a valid set of node types, but didn't actually create the tables for some reason. Perhaps I'm missing something here.

mathieu’s picture

mathieu commented

We did the upgrade, using export/import, but I did wipe all the content type related tables before re-importing the data. This worked for us, but it's definitely an awkward feature, if not a bug. The special thing here, afaik, is that some field were shared between content-types for some time... If I understand cck correctly, this explains the creation of those extra tables..

Sorry if I'm off-target, I didn't have much time to explore all of this and the problem is fixed for us.

dopry’s picture

dopry commented
Status: Active » Postponed (maintainer needs more info)

Can you be more explicit about the state of the db before and after the update? Can you give us a subset of your db that we can test the upgrade path on? an export of your content type we can test upgrading against?

lewisholden’s picture

lewisholden commented

I'm having a similar problem upgrading from 5.x-1.4 - 5.x-1.9

Has anyone had any luck with any of these fixes?

karens’s picture

karens commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

Old issue on old version without enough info to respond, and no one has time for D5 support anyway.