This error happens frequently but not with every node save. When one edits an existing node and then saves it, we get the error

user warning: Duplicate entry '474-0' for key 1 query: INSERT INTO term_node (nid,tid) VALUES (308,474) in /var/www/drupal/sites/all/modules/taxonomy_access/taxonomy_access.module on line 390.

474-0 varies from error to error.
key 1 query is consistent.
The first number in the VALUES pair is always the node id.

This error is not necessarily triggered by editing a specific field on the node, it happens when we edit the taxonomy terms, the body, or the input format.

We've been getting this error for a while, but didn't worry about it because it wasn't affecting the way the nodes were presenting to the public. However, today I had the need to check which taxonomy term had been assigned to a bunch of different nodes, and I found that a lot of nodes had switched terms for no apparent reason (although, possibly at the time when a translation was being created for the node.)

I've described the problem as completely as I know how, but I'm not a programmer. If you need us to look at the mysqul logs, we can do that, but please be specific about what we're looking for.

Thanks for any help you can give.

Comments

cpugeniusmv’s picture

Component: User interface » Code

If this is still a problem, it's most likely an issue with the taxonomy_access_preserve_terms/taxonomy_access_restore_terms functions.

Have you found a reliable way to reproduce this issue?

xjm’s picture

Status: Active » Postponed (maintainer needs more info)

Marking postponed pending followup from the OP.

xjm’s picture

I wonder if this was a freetagging vocabulary.

In any case, TAC should not perform any operation if $tid is zero, so we can at least add a check for that in the preserve/restore terms functions.

xjm’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

Oh... it's the $nid that's coming up zero, not the $tid. That means it's extremely unlikely this could have been an issue with TAC. Closing issue since there's been no followup and (based on how old it is) is probably fixed or no longer relevant.