Drupal: strange MySQL "table doesn't exist" error caused by CCK, Features and Strongarm

Ran into a bit of a strange error today; I was getting a Drupal "table not found" SQL error on my live site after pushing an updated feature from the dev site, and then reverting the feature to get the settings back to default.

The query was:

user warning: Table 'greyhead.node_field_instance' doesn't exist query:
SELECT * FROM node_field_instance nfi 
LEFT JOIN node_field nf ON nf.field_name = nfi.field_name 
WHERE nf.active = 1 AND nfi.widget_active = 1 
in <noodle foo bar>/sites/all/modules/cck/content.install on line 187.

... So I dived into the CCK module's content.install and line 187 called this function: content_instance_tablename(), which I tracked down to content.module, where the function calls this: variable_get('content_schema_version', 0);

On both dev and live sites, this returns 6009, so the content_instance_tablename() function should return a value of content_node_field_instance, but instead seems to be returning a value which is evaluating to < 6001; i.e. the function returns the old CCK schema table name of node_field_instance, and this breaks any queries which rely on this value.

Putting two and two together, my guess was that Strongarm is over-writing the content_schema_version value in the {variable} table at some point during the execution of certain pages, which is breaking CCK's variable_get call.

So I hopped over to the command line to look into the feature files for "content_schema_version"; cd'ing to the feature's directory, I ran:

grep -irn "content_schema_version" *

... which showed that the variable was defined in the feature:

That Strongarm value

... but that it was providing the right value of 6009. At this point I figured that I was likely to be running into a strange issue being caused by the variable_get running during a variable_set, or some other such voodoo-based weirdness. Easy solution? Remove the field's definition from the feature and allow CCK to look after provision of that variable au-naturel.

So, in the end I simply recreated the feature from the live site (admin > build > features > greyhead settings > recreate) and under the Strongarm drop-down, unticked the checkbox for content_schema_version. Then I re-exported the feature and unpacked it into my MAMP localhost install, did a git commit on the localhost followed by a git push, the over on the server did a git pull, followed by drush cc all and a drush updatedb, just for good measure. Finally, I had to run variable_set('content_schema_version', 6009); using the Devel module.

Touch wood, so far, I haven't seen that error since.

Very odd...


Attached files: 


Dominique De Cooman (not verified) wrote 4 years 5 weeks ago

Is there an issue on drupal.org for this? Like to know the real cause of this problem? Thx for the solution!

Alex Harries wrote 4 years 5 weeks ago

Hey Dominique, I couldn't find any useful information on this issue anywhere when I searched. If I knew more about the exact nature of the problem, I'd be happy to have a go at committing a patch; sadly, I didn't get further than identifying *what* was wrong.

All the best,


Daniel Lopez (not verified) wrote 4 years 3 weeks ago

The issue, at least as i'm encountering it is:

When accidentally selecting content_schema_version for with strongarm in features. When exporting it it gives me the error.

The same as the original poster, when trying to re-create the feature after unselecting "content_schema_version" from the list of strong arm settings. It still appears after exporting.

Hopefully i wont have to throw in a variable_set, just looking into this now.

stevenator (not verified) wrote 3 years 43 weeks ago

I also wanted to say thank you. there is an actual issue being tracked on D.O. and it ends in the very same solution which is manually settings the variable. Instead of rebuilding the feature you could run your own hook_update_N in a module or directly using the admin module

Here's the issue and thanks again! Hope you are going to DrupalCon!!!


Please register or login to post a comment.

Most-mentioned in the blog