The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.After installing glossary 5-2.2 the log fills with below messages, I didn't see these on my test system.
The production site runs MySQL 4.1.15
Unknown table 'term_data' in where clause query: SELECT t.name, t.description, t.tid, COUNT(tn.nid) as nodes FROM term_data t LEFT JOIN term_node tn USING(tid) WHERE (term_data.tid IN ('14','16','25','26','30','31','32','33','34','35','38','39','43','44','48','49','50','51','55','57','58','59','60','61','62','115','116','117','118','119','136','145','148','150','175','176','183','184','185','186','187','189','191','193','194','195','196','197','198','199','200','206','211',� in ...../includes/database.mysql.inc on line 172.
Comments
Comment #1
nancydruAre you using i18n? http://drupal.org/node/233688 added the db_rewrite_sql that I assume is messing up here.
Also, please ask you host to move to a supported release of MySql; MySql 4.x is no longer supported, and Drupal 7.x will not work with it.
Comment #2
jvlagsma commentedHi Nancy, No I'm not using i18n, I have a single language website so locale is hopefully enough. Is Glossary now dependant on i18n?
I don't really understand what's happening with the errorcode, do you? It looks like a variable is being expanded into an incorrect character set or something? I cannot relate it to the query in the glossary code that sends the query. And, is this MySQL related or maybe PHP version related?
I'll need to talk to my host anyway, PHP 4 is also becoming an inhibitor for change.. the're conservative but very stable ;-)
Comment #3
jvlagsma commentedI'm now seeing the problem on my test system as well, to trigger it apparently needs entering new nodes? Anyway, this makes the problem happen on both PHP 4 and 5 and both on MySQL 4 and 5.
Comment #4
nancydruIt is not intended to be dependent on i18n. Certainly it works fine on my English sites with no translation. I was asking because the change was implemented for i18n.
I don't think it is either MySql or PHP related. I think it's either with the way I did the db_rewrite_sql or some module that implements hook_db_rewrite_sql (notably i18n and most access control modules).
I'll take a look again at the code.
----------------------------------------------------------------------------------------------------------------------
A lot of people are not aware yet that Drupal 7 (due in about 10 months) will only support MySql 5+ (or Postgres 8+) and PHP 5.2+ (probably 5.2.5 or higher). And MySql 4.x is no longer supported by the vendor - and hasn't been for a while now. In order for Drupallers to be ready for this, now is the time to be pushing the recalcitrant hosting companies. BTW, 6.x already requires a minimum of 16 MB, which some hosts won't allow.
Comment #5
nancydru@Johan, here is a quick test for you to please try (I cannot reproduce this, obviously).
Line 794 is
$result = db_query(db_rewrite_sql('SELECT t.name, t.description, t.tid, COUNT(tn.nid) as nodes FROM {term_data} t LEFT JOIN {term_node} tn USING(tid) WHERE t.vid=%d GROUP BY t.tid, t.name, t.description ORDER BY LENGTH(t.name) DESC', '{term_data}', 'tid'), $vid);Please change the
'{term_data}'near the end with't'Comment #6
jvlagsma commentedSorry Nancy, that does not solve the problem.
I'm not using prefixed tables so '{term_data}' and 'term_data' should produce the same table (eventhough not drupal compliant)?
With the 't' replacing '{term_data}' the error message is still the same, I'd expect it to name t but it still names term_data (see below)
Unfortunately I cannot reproduce at will but on the production site there's a continuous stream of these messages as users do their stuff.
Note the errormessage in the topic start is formatted by drupal.org, in reality it looks a bit different with many '& # 039;' in there but without the spaces.
Comment #7
jvlagsma commentedHad a closer look, turns out I changed the wrong query and your change in #5 does work fine!
Feeling a bit foolish now.. I shall get a proper text editor with line numbers..
There are a couple of other occurrances also using '{term_data}' or similar bracketed tablename in the 2nd argument of db_rewrite_sql. I've changed all of them to get rid of all the error messages but the one you mentioned was the largest contributor ;-)
So aparently db_rewrite_sql doesn't like bracketed db name as 2nd argument, is that documented? Does it need a bug report?
Comment #8
nancydruIt's "sort of" documented. It's one of those cases where if you know what you're looking at, it's there. I discovered this by accident when looking closely at the taxonomy module shortly before suggesting that change. I will go and hit all of those queries.
Someone recommended Notepad++ to me a few months ago and I'm using it almost exclusively now. It's open source (as in free). It's fast and has a bunch of neat features. The only thing that bugs me with it is lack of line wrap, but it does scroll right to see the end.
Comment #9
luti commentedBe careful, sometimes (more at the end) it is 't', but sometimes (more at the beginning) it is 'td'!
Comment #10
jvlagsma commented@ LUTi: that's right, there's even a v there for vocabulary or something (can't check right now). I did a find on all db_rewrite_sql's and changed them all as appropriate.
@ nancyw: Thanks for the hint, good to have this solved :-)
Comment #11
nancydruThat parameter is the "Name or alias of the table which has the primary key field" so it will vary depending on the tables that are being accessed. And yes I noticed that the code has "t" for an alias in some places and "td" in others. I'm guessing "td" is used on the ones I wrote or modified, and "t" on older queries. I guess I could work on standardizing that.
Comment #12
nancydruFix committed. The alias is "td" throughout now.
Comment #13
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.