I'm running into a problem where I get PDOExceptions thrown about unknown collumns.

I did see a couple bug reports about it in the issue queue, but they were marked as fixed. If I've overlooked an existing ticket, please feel free to close this issue and send me to the duplicate.

Here's how I produced the error:
- A Drupal install with field translation, entityreference and multilingual select turned on.
- I have two content types, "news" and "news category".
- Both content types use field translation as provided by the entity translation module.
- Both content types have the title replaced by an actual field, using the title module.
- Both content types have a default language set to "dutch", this language cannot be changed once applied and the language neutral option is disabled.
- The "news" content_type contains 1 entity_reference field.
- The entity_reference field is not translated.
- The entity_reference field can only reference nodes of type "news_category".

Expected behavior:
- To be able to create news_category nodes and news nodes.
- To be able to select a news_category node using the entity_reference field on the news node form.
- Because both content_types use field translation, I expect the nid to remain the same across translations (This is how field_translation works, right?)
- Because the entity_reference field is set to be not translatable, nodes are related by nid, and nid's don't change amongst translations, the nodes should then be related across translations.

Actual behavior:
- The following error when viewing, creating or editing a node of content_type 'news':

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_data_title_field0.nid' in 'on clause': SELECT DISTINCT field_data_title_field0.entity_type AS entity_type, field_data_title_field0.entity_id AS entity_id, field_data_title_field0.revision_id AS revision_id, field_data_title_field0.bundle AS bundle FROM {field_data_title_field} field_data_title_field0 INNER JOIN {node} node ON field_data_title_field0.nid = node.nid WHERE (field_data_title_field0.deleted = :db_condition_placeholder_0) AND (field_data_title_field0.entity_type = :db_condition_placeholder_1) AND (field_data_title_field0.bundle IN (:db_condition_placeholder_2)) AND (node.language IN (:db_condition_placeholder_3, :db_condition_placeholder_4)) ORDER BY field_data_title_field0.title_field_value ASC; Array ( [:db_condition_placeholder_0] => 0 [:db_condition_placeholder_1] => node [:db_condition_placeholder_2] => news_category [:db_condition_placeholder_3] => en [:db_condition_placeholder_4] => und ) in field_sql_storage_field_storage_query() (line 582 of /home/ruben/Eclipse Workspaces/Usendes/epst2/modules/field/modules/field_sql_storage/field_sql_storage.module).

I can spend a few hours trying to fix things, but I'm not familiar with either the source of either entity_translations or entityreference or even the entity API. So if anyone can point me in the right direction or if anyone knows a solution to this, any help is very much appreciated.


ruben_vreeken’s picture

Allright, so I found some more information. As it turns out, the problem only occurs if I turn on the "Multilingual Select" module.

Turning it off fixes the problem, but it's not a real solution because that causes my referenceable entities to always display in English, regardless of the interface or content language. While of-course the desired behavior would be to display the referenceable entities in the interface language.

I've updated my original post to add this to the list of things to do to reproduce the error.

khli7’s picture

Assigned: Unassigned » khli7
Status: Active » Needs work

Dear Sir/Madam,

I have just downloaded and and am now going to install a nice design theme Designmd01 - Responsive Drupal 7" from themeforest webpage.

[the rest of the post has been cut away by hansfn since it wasn't related to this module]

orbistertius’s picture

Component: Code » Documentation
Assigned: khli7 » Unassigned
Priority: Major » Minor
Status: Needs work » Active

I had the same problem but using the views entity reference widget with the views field of the title replaced by the title_field solved this. I do not think that this is something to solve in code than in configuration. I guess that #2 may have other reasons. Regards

hansfn’s picture

hansfn’s picture

Issue summary: View changes

Added multilingual select module to error reproduction instructions

doub1ejack’s picture

FYI, this is the same issue I am having, but I do not have this module installed. Also, I do not see this error when logged in as the primary administrator, but when logged in as a mid-level user I get the same error when I try to create a new node. Perhaps that will provide some troubleshooting clues.

commonpike’s picture

Had the same as the op and nearly the same setup.

The error occurred when I wanted the referenced nodes to be sorted by a field (the title) in the edit form.
When I disabled sorting for the referenced nodes (in the node reference field settings), the error went away.

So I assume ``Unknown column 'field_data_title_field0.nid' `` is refering to the referenced nodes titles, not the current nodes title.

Hope it helps someone. It smells like a bug, but I dont feel confident enough to submit a report.


beyond_a_joke’s picture

I fixed this problem by running update.php

ehj-52n’s picture

The removal of the ordering from the field settings as outline by #6 did the job for me.

Running update.php did nothing.

Zekvyrin’s picture

Happened to me as well.

Also "solved" it by removal of ordering, but that isn't exactly "solving it".

update.php didn't fix anything.

DigitalFrontiersMedia’s picture

bkat’s picture

I too am having the problem. In my case, I have two content types Game and Team. Each of these has an entity reference to League.

For the entity reference field, field_league I'm using Simple mode with target bundle league and have specified to sort by field_start_date.

When the available options is being built, the query is tagged with both 'node_access" query_TAG_alter() and 'entity_access' query_TAG_alter.

In this query, the only table is field_data_field_start_date and the two query_TAG_alter hooks are mutually exclusive. Both functions are implemented in node.module as

function node_query_node_access_alter(QueryAlterableInterface $query) {
  _node_query_node_access_alter($query, 'node');

function node_query_entity_field_access_alter(QueryAlterableInterface $query) {
  _node_query_node_access_alter($query, 'entity');

the second parameter to _node_query_node_access_alter() is hard coded and determines which column from the table will be joined with node_access.nid.

Thus I am ending up with field_data_field_start_date.entity_id = na.nid AND field_data_field_start_date.nid = na.nid in different subqueries I believe.

I don't know where the tags are getting added but I don't think we should tagging these sub queries with both entity_access and node_access tags.

  1. EntityReference_SelectionHandler_Generic.buildEntityFieldQuery() adds node_access tag to the EntityFieldQuery on league
  2. When entity field query is executed, field_sql_storage_field_storage_query() creates a select_query for the field that is being sorted on.
  3. field_sql_storage_field_storage_query then calls $query->finishQuery() and passes the select_query to it.
  4. EntityFieldQuery.finishQuery() adds all tags from the parent query to the select query. This adds node access in addition to entity_field_access that is already there.

So far my best work around is to change entity.inc from

function finishQuery($select_query, $id_key = 'entity_id') {
    foreach ($this->tags as $tag) {


function finishQuery($select_query, $id_key = 'entity_id') {
    foreach ($this->tags as $tag) {
      if ($tag == 'node_access' && !isset($select_query->alterTags['entity_field_access'])) {

I have node idea what kind of issues this may cause or even if the root cause is that EntityReference_SelectionHandler_Generic.buildEntityFieldQuery() is adding "node_access" tag to the query.

bkat’s picture

I can confirm that the patch referenced in #10 does indeed solve this issue! Thanks for cross posting here as that bug wasn't on my radar.