Lastest dev version cause me following two errors:
user warning: Unknown column 'node.nid' in 'on clause' query: SELECT COUNT(*) FROM (SELECT DISTINCT(node.nid) AS nid FROM node node WHERE (node.status <> 0 OR node.uid = 0 or 0 = 1) AND (node.vid IN ( SELECT tn.vid FROM term_node tn INNER JOIN node_access na ON na.nid = node.nid WHERE (na.grant_view >= 1 AND ((na.gid = 0 AND na.realm = 'all') OR (na.gid = 0 AND na.realm = 'view_own_owner') OR (na.gid = 1 AND na.realm = 'view_own_role'))) AND ( tn.tid = 23 )) )) count_alias in /sites/all/modules/contributions/views/includes/view.inc on line 697.
user warning: Unknown column 'node.nid' in 'on clause' query: SELECT DISTINCT(node.nid) AS nid, node.sticky AS node_sticky, node.created AS node_created FROM node node WHERE (node.status <> 0 OR node.uid = 0 or 0 = 1) AND (node.vid IN ( SELECT tn.vid FROM term_node tn INNER JOIN node_access na ON na.nid = node.nid WHERE (na.grant_view >= 1 AND ((na.gid = 0 AND na.realm = 'all') OR (na.gid = 0 AND na.realm = 'view_own_owner') OR (na.gid = 1 AND na.realm = 'view_own_role'))) AND ( tn.tid = 23 )) )ORDER BY node_sticky DESC, node_created DESC LIMIT 0, 10 in /sites/all/modules/contributions/views/includes/view.inc on line 723.
after I'm clicking specified tag in block (uri: /category/tags/drupal).
I don't have this problem, when I'm logged in as admin.
Any ideas?
Comments
Comment #1
kenorb commentedProbably the reason is when I've enabled `taxonomy_term` view.
After I disabled it, there is no error. But MySQL syntax should be fixed.
Comment #2
merlinofchaos commentedThat error makes no sense. It says your 'node' table has no 'nid' column. That's...not possible.
Comment #3
jthaxton commentedI get this error as well for a View on my site:
From what I can tell, the table alias is being referenced before the table alias is set (at least in my instance) in the second line. The alias is calling from the 'node' table so if I update the query and run it in mysql (outside of Drupal) the replacement for the alias works. Does that help?
It appears that I can have an argument or a relationship, but not both.
Comment #4
jthaxton commentedAs long as I leave the "use relationship" field empty in my argument, I can totally get rid of the error and get data back. Sorry to post twice and resolve my own issue along the way but perhaps this will help? Thanks!
Comment #5
aelling commentedI receive the same error as previously posted. The view works fine when logged in as an administrator, but as an anonymous user the following error is generated.
Comment #6
merlinofchaos commentedThis would appear to be another case of core's db_rewrite_sql improperly rewriting a query. It is rewriting the sub select rather than the primary select. :/
Comment #7
d0t15t commentedhi,
i get the same warning as above but doubled:
any clues on potential fixes? i ran suspect query on mysql out of drupal and got the results i was looking for. it only seems broken w/i drupal framework...
any hints would be appreciated.
Comment #8
Anonymous (not verified) commentedSorry wrong place to suubmit
Comment #9
kenorb commentedDuplicates:
#40623: Bad interaction with MySQL 5 & Image & Event modules
#51850: nailing down db_rewrite_sql (mysql 5)
#46864: SQL error when anonymous: Unknown column 'n.nid'
#303906: SQL Error: Unknown column 'n.nid'
#357073: Getting `Unknown column 'n.uid' in 'field list'` Error After Installing Storm
http://drupal.org/node/43735
Can be related:
#51842: SQL errors when enable access control under settings-->og-->module status
http://drupal.org/node/238873
http://drupal.org/node/58719
Comment #10
kenorb commentedJoin Processing Changes in MySQL 5.0.12
Beginning with MySQL 5.0.12, natural joins and joins with USING, including outer join variants, are processed according to the SQL:2003 standard. The goal was to align the syntax and semantics of MySQL with respect to NATURAL JOIN and JOIN ... USING according to SQL:2003. However, these changes in join processing can result in different output columns for some joins. Also, some queries that appeared to work correctly in older versions must be rewritten to comply with the standard.
Read more: http://dev.mysql.com/doc/refman/5.0/en/join.html
Explanations of the issue:
http://drupal.org/node/40623#comment-362005
http://drupal.org/node/43735#comment-92865
Here you will find my quick-fix to hide those error messages for all users apart admin:) http://drupal.org/node/342128#comment-1203466
Comment #11
d0t15t commentedthanks!
Comment #12
kenorb commentedPossible quick fix with parenthesis:
http://bugs.mysql.com/bug.php?id=13832
in the bottom
Comment #13
Anonymous (not verified) commentedComment #14
kenorb commentedWhy you closed? It's not fixed.
Comment #15
Anonymous (not verified) commentedI closed it cause after upgrading drupal, it was sorted
Comment #16
kenorb commentedOk, I didn't know.
How it's possible?
Any link to solution patch?
Comment #17
agileware commentedThis is active as there are no patches to review.
I don't know about drupal 6 but in drupal 5 I had this problem:
any sub-queries in my sql that was passed through db_rewrite_sql was mangled
because it runs on all WHERE's in the sql, even the subqueries.
A workaround I used from D5 was to have "where" in lower case in my sub-queries.
Because db_rewrite_sql looks for WHERE in uppercase it leaves my sub-queries alone.
Again, that is in drupal 5, I haven't looked into it for drupal 6.
Comment #18
agileware commentedAlso, if you have in your subquery GROUP, ORDER BY or LIMIT db_rewrite_sql will close it parentheses in between your WHERE and whichever of those you are using.
This will cause you SQL errors.
To get around this you can also just use lower case for these as it only checks for them in upper case.
Comment #19
dpearcefl commentedHas this issue been fixed in the latest D6?
Comment #20
dpearcefl commented