Pages tagged with: "mysql"

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 = 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: 
Syndicate content