I'm using Drupal 7.14 and Entity API and Reference 1.0-rc3.

And I'm also using i18n, entityreference (not References) and field_sql_storage.

I get this error when saving a node that has some custom fields using references.

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_data_body0.nid' in 'on clause': SELECT field_data_body0.entity_type AS entity_type, field_data_body0.entity_id AS entity_id, field_data_body0.revision_id AS revision_id, field_data_body0.bundle AS bundle FROM {field_data_body} field_data_body0 INNER JOIN {node} node ON field_data_body0.nid = node.nid WHERE (field_data_body0.deleted = :db_condition_placeholder_0) AND (field_data_body0.entity_type = :db_condition_placeholder_1) AND (field_data_body0.bundle IN (:db_condition_placeholder_2, :db_condition_placeholder_3)) AND (field_data_body0.entity_id IN (:db_condition_placeholder_4)) AND (node.language IN (:db_condition_placeholder_5, :db_condition_placeholder_6)) ORDER BY field_data_body0.body_value ASC; Array ( [:db_condition_placeholder_0] => 0 [:db_condition_placeholder_1] => node [:db_condition_placeholder_2] => news [:db_condition_placeholder_3] => page [:db_condition_placeholder_4] => 25 [:db_condition_placeholder_5] => it [:db_condition_placeholder_6] => und ) in field_sql_storage_field_storage_query() (linea 577 di /home/morpheu5/web/xdatanet/modules/field/modules/field_sql_storage/field_sql_storage.module).

What bothers me is that, first of all there's a zero appended to the name of the table, and second, if I add that nid column to that table, Drupal is happy and everything seems to work.

I suspect there must have been some update gone horribly wrong, since maintenance is not under my control, and I had to implement some new features working on my local copy which at that time was already completely out of sync with the client's staging and production servers.

I tried a number of patches, and I've gone through the code myself but I'm not this familiar with Drupal.


It seems the nid column is getting added at some point in function preExecute in includes/database/select.inc specifically at row 1236

drupal_alter($hooks, $query);

the hooks acting here are

  • query
  • query_entity_field_access
  • query_node_access
  • query_entityreference

but after a hour long investigation I only came up with a huge headache, and I'm still not sure if I actually found and debugged all of those hooks. As far as I could see, the nid column is not present before the drupal_alter call while it is after, but it's there at the beginning of each hook_query_TAG_alter I was able to find.

I must be missing something.


The culprit seems to be i18n, specifically i18n_select, more specifically at row 137 of i18n_select.module where it adds the nid column.


There, I opened a bug: https://drupal.org/node/1679646

  • I had a similar problem some time ago and I think the problem was with the references module. You should have a look at this drupal.org/node/1275096. There is a patch called column_not_found_1054_unkonw_column-1275096-8.patch which solved my problem. Jul 19, 2012 at 4:20
  • Unfortunately I'm not using the references module but the entityreference one. I tried looking at that patch but it didn't seem like it could be translated.
    – Morpheu5
    Jul 19, 2012 at 14:22

1 Answer 1


The body field should definitively NOT have a nid column in the table. The field_data_body table provided by core will contain an entity_id column which is the reference to the node entity.

2 things I can think of that might be causing this:

  1. You have custom code that's making an erroneous database query in a hook_node_load() function or similar (either directly or using an EntityFieldQuery)
  2. (more likely I think) Core/contributed modules or files have been edited and the changes are only now causing problems.

The best advice I can give is to install the Hacked! module and determine whether or not core/contributed modules have indeed been hacked. If that comes back all clear then you're just looking at an error in some custom code somewhere which will be easy to track down.

If it doesn't come back clear, at least you know what the problem is and you can then decide how best to proceed with getting Drupal back into a proper un-hacked state.

Incidentally, don't worry about the table being referred to as field_data_body0...if you look further down in the query that's just an alias that's being used for field_data_body:

FROM {field_data_body} field_data_body0
  • Thanks, I'll let you know. That Hacked! module is completely new to me :)
    – Morpheu5
    Jul 10, 2012 at 12:45
  • Apparently neither the core nor contributed modules have been modified significantly: just a couple of completely unrelated lines but I managed to get them back in place and the error is still there. I also have a couple of custom modules made using Features and, as far as I know but I can't be 100% sure, this problem started after they installed these two modules I made. Neither of these appear to reference anything related to nid, though.
    – Morpheu5
    Jul 10, 2012 at 13:25
  • I updated the question.
    – Morpheu5
    Jul 10, 2012 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.