When I run a cron manually from the Status Report screen, I get the following error:

* user warning: Duplicate entry '8' for key 'PRIMARY' query: INSERT INTO node_expire (nid, expire, expired) VALUES (8, 0, 0) in /mydomainname/includes/common.inc on line 3422.
* user warning: Duplicate entry '9' for key 'PRIMARY' query: INSERT INTO node_expire (nid, expire, expired) VALUES (9, 0, 0) in /mydomainname/includes/common.inc on line 3422.
* user warning: Duplicate entry '10' for key 'PRIMARY' query: INSERT INTO node_expire (nid, expire, expired) VALUES (10, 0, 0) in /mydomainname/includes/common.inc on line 3422.
* user warning: Duplicate entry '11' for key 'PRIMARY' query: INSERT INTO node_expire (nid, expire, expired) VALUES (11, 0, 0) in /mydomainname/includes/common.inc on line 3422.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

marioe2000’s picture

Same problem here... only difference is that I get it for only two records.

zarudnyi’s picture

Same problem

Duplicate entry '506' for key 1 query: drupal_write_record /* Administrator : drupal_write_record */ INSERT INTO node_expire (nid, expire, expired) VALUES (506, 0, 0) in /home/folder/data/www/domain/includes/common.inc on line 3422.

smsearcy’s picture

Try changing the code at line 53 in node_expire.nodeapi.inc from:

    case 'insert':
      $update = array();
      if (isset($node->node_expire)) {
        $update[] = 'nid';
      }

to

    case 'insert':
      $update = array();
      if (isset($node->expire)) {
        $update[] = 'nid';
      }

It wasn't properly detecting if it was editing an existing record.

zarudnyi’s picture

Hi, smsearcy!
Thanks for your reply.
You code work fine, my problem is completely solved.

smsearcy’s picture

Status: Active » Needs review
FileSize
435 bytes

Here's a patch for code change in comment #3. I think I created it correctly, please let me know if there is a problem.

smsearcy’s picture

FileSize
737 bytes

I ran into an issue with my previous patch of not being able to add an expiration date to an existing node without an expiration date (I think because it was attempting to update a non-existent record in {node_expire}), so I rewrote the insert/update section. This hopefully will also address #466680: Nodes saved in node_expire table with value of 0 then unpublished by not saving an empty expiration date in the table (and will clean up the table).

    case 'update':
    case 'insert':
      db_query('DELETE FROM {node_expire} WHERE nid = %d', $node->nid);
      if (empty($node->expire)) {
          // don't save an empty expiration date in the database
          break;
      }
      $node->expire   = strtotime($node->expire);
      $node->expired  = FALSE;
      db_query('INSERT {node_expire} (nid, expire, expired) VALUES(%d, %d, %d)', $node->nid, $node->expire, $node->expired);
      break;

I've attached a patch, which hopefully is correctly formatted (I'm stuck running Windows).

smsearcy’s picture

FileSize
765 bytes

Minor formatting change to previous post, and removed the second point from the case statement.

    case 'update':
    case 'insert':
      db_query('DELETE FROM {node_expire} WHERE nid = %d', $node->nid);
      if (!empty($node->expire)) {
        $node->expire   = strtotime($node->expire);
        $node->expired  = FALSE;
        db_query('INSERT {node_expire} (nid, expire, expired) VALUES(%d, %d, %d)', $node->nid, $node->expire, $node->expired);
      }
      break;
arthurf’s picture

FileSize
1.13 KB

Here's a slight variation on the above patch- removes the the $update array and uses the drupal_write_record fuction instead of the db_query. It also prevents makes the delete query conditional. I'm not sure if there is ever a condition where this would be the case, but seems like it might be a good idea to check for it.

barckhoff’s picture

Excellent! Thank you so much for posting this -- I installed the arthurf patch (#8 above) and it seems to be working for me.

Any idea how to stop node expire from subtracting a day from the expiration date every time a node is edited? (See http://drupal.org/node/435658)

smsearcy’s picture

I tested arthurf's patch (#8) when adding/modifying/deleting expiration dates on new and existing nodes and didn't find any issues. Thank you.

p4trizio’s picture

Hi guys! Isn't it time to make a new release of this module? With all this patches... I'm lost! ;-)
Can someone post the MUST patches of this module? Just a simple list to make it work in a good way.
Thank you!

Summit’s picture

Hi, I think committing the working patches in a .dev would be the best way, because maybe there is also a working order for the patches to commit properly, right? Then after testing making a 2.04 or 2.1 please.
Thanks a lot in advance for considering this!
Greetings, Martijn

the.alphy’s picture

I'm having this same error. How test/stable is the patch? Does anyone know when it will make it's way into 2.04/the next version?

JamesAn’s picture

Status: Needs review » Reviewed & tested by the community

The patch in #8 works for me too. I took a quick peek at the PHP code and it makes sense to me.

Maybe if we RTBC this, one of the committers will take notice.

the.alphy’s picture

Yeah, I tested the patch as well and it seems to fix the problem so far.

zapscribbles’s picture

Subscribe, I've been having the same issue

siliconmeadow’s picture

Just to let you know, I too have run this patch (#8) five months since the last report and it worked fine. I guess it's reassuring that the patched code hasn't gone stale in that time.

:-)

fletch11’s picture

I'm still getting this meassage. Has this been applied to the latest version?

opteronmx’s picture

Confirmed, #8 arthurf's Patch applied against current stable version, works fine, cron errors gone away!

Thanks arthurf

Mac Clemmens’s picture

Same problem. #8 worked for me. Thanks!

vikramy’s picture

Status: Reviewed & tested by the community » Closed (fixed)

Fixed.. Thanks for the patch..