Unknow column 'n.language'

i encountered this error too, help

I have also seen this warning in a couple of other modules (evoc, for one). I can't tell if it's somewhat related to the latest release of Drupal6 or possibly an update to the views, cck, or i18n modules I recently made but I'm not seeing it on a site which has older versions of those modules.

I am able to get rid of it by either removing the function call to db_rewrite_sql or changing the query as follows:

at line 256, for example:
change this:
$class = db_query(db_rewrite_sql("SELECT class FROM {rdfcck_content_types} WHERE type_name = '%s'"), $type_name);

to this:

$class = db_query(db_rewrite_sql("SELECT n.class FROM {rdfcck_content_types} n WHERE n.type_name = '%s'"), $type_name);

After further investigation...

The suggested change that I proposed above would not work. I'd fixed the problem in another module that was querying the node table and it worked because the node table does have a language column, however none of the tables being queried in the rdfcck module using db_rewrite_sql contain a language column. Looking at the code in database.inc is making me think that it's an issue with the i18n module.

Okay, I've looked at this a bit further...

The problem, as I see it, is in the i18n module, and perhaps just weak documentation for the db_rewrite_sql function in the API documentation.

The db_rewrite_sql function takes several optional arguments and the API docs describe the calling signature as follows:

db_rewrite_sql($query, $primary_table = 'n', $primary_field = 'nid', $args = array())

Note, that the $primary_table argument is optional, and if not provided will default to "n". First, I think that's a bit of a bug in the db_rewrite_sql function. If I write a query such as "SELECT n.* from {node} n", the "n" is not a table name, but rather an alias for the table called "node".

When the db_rewrite_sql function executes the first thing it does is call the module_implements function to determine which modules in the site implement the db_rewrite_sql hook then executes a module_invoke (thus calling, i18n_db_rewrite_sql when the i18n modules is enabled).

When I posted the compatibility issue as an i18n issue someone claimed that the implementation should only rewrite queries with the node table is referenced. That's actually not true. There is a switch/case statement on the $primary_table string that is passed to the implementation. It tests if it equals "node" *OR* "n" (which is what's going to get passed if the db_rewrite_sql function is called without specifying the $primary_table argument). As a result, if the i18n module is enabled almost any query wrapped by the db_rewrite_sql function is going to get the WHERE clause added (using a "n" for the table alias) if the function is not called with the $primary_table argument specified.

In order to prevent the i18n_db_rewrite_sql function from rewriting the query you need to specify the table name you're referencing. Doing so will still allow the node_db_rewrite_sql() hook to execute (thus performing the node access checks) but won't break queries which are referencing tables which do not have a 'language' column.

I had hoped that simply adding a test in the i18n module to check for the existence of the language column before rewriting the query would fix things but it's not quite that simple. The db_column_exists($table, $column) function will return true if a column exists in a specified table, however, if the table name does not exist, it will produce an error. The docs for db_column_exists suggest called db_table_exists() first to test if the table exists. However, remember that the db_rewrite_sql core function sets the $primary_table to 'n' if the argument is not specified? When when you pass 'n' as the table name to the db_table_exists function it will return false because "n" is an alias, not a table name. Thus, the i18n implementation can't use the db_column_exists function to test if a language column exist if it's going to try to rewrite queries when the $primary_table name is "n".