Duplicate entry for key PRIMARY

+1 on the 7.x verion
Integrity constraint violation: 1062 Duplicate entry

I got the same error recently.

Reason :
We are quering a count of rows that look like our to decide whether we need to insert it or to update.
The bug is in the conditions, they are to strong, we don't ever find anything.
Count is always 0, we are trying to insert - and catching an error about duplicate primary key value.

How to solve :
Delete "Bundle" from query conditions because it IS NOT IN PRIMARY KEY.

Please review the patch.
I have tested it myself - it works.

Discovered that we need to delete this too strong condition from db_update also.
Otherwise we got no errors but no updating too.
Tested on self skin. :)
Please review.

We should not port it until we receive feedback about 7.x version.
Also I don't have D6 installed to see what is the problem there and how to port this patch.
Robert, I recommend you to look into these lines :

    db_query("UPDATE {" . $db_table . "} SET `" . $field_db_column_name . "` = " . db_type_placeholder($field_db_column_type) . " WHERE `vid` = %d", $node_field[0]['value'], $result->vid);
    if (db_affected_rows() < 1) {
      // Entry is not yet created, so lets insert.
      db_query("INSERT INTO {" . $db_table . "} SET `" . $field_db_column_name . "` = " . db_type_placeholder($field_db_column_type) . ", `vid` = %d, `nid` = %d", $node_field[0]['value'], $result->vid, $node->nid);
    }

You should debug them to find the problem in 6.x case.
Hope it helps.

This didn't work for me. I still get:

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /batch?id=15&op=do StatusText: Service unavailable (with message) ResponseText: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'node-1-0-0-nn' for key 'PRIMARY': INSERT INTO {field_data_field_remaining} (entity_type, bundle, deleted, entity_id, revision_id, language, delta, field_remaining_value) VALUES (:db_insert_placeholder_0_entity_type, :db_insert_placeholder_0_bundle, :db_insert_placeholder_0_deleted, :db_insert_placeholder_0_entity_id, :db_insert_placeholder_0_revision_id, :db_insert_placeholder_0_language, :db_insert_placeholder_0_delta, :db_insert_placeholder_0_field_remaining_value); Array ( [:db_insert_placeholder_0_entity_type] => node [:db_insert_placeholder_0_bundle] => income [:db_insert_placeholder_0_deleted] => 0 [:db_insert_placeholder_0_entity_id] => 1 [:db_insert_placeholder_0_revision_id] => 33 [:db_insert_placeholder_0_language] => nn [:db_insert_placeholder_0_delta] => 0 [:db_insert_placeholder_0_field_remaining_value] => 2950 ) in _computed_field_tools_batch_recompute() (line 513 av /home/wizonesolutions/domains/example.no/public_html/drupal/sites/all/modules/computed_field_tools/computed_field_tools.module).

The weird thing is that it's even trying do an INSERT. The field almost certainly already exists. I'll dig in a bit and see what I can find.

Actually, this might be a data issue on my own site. I suspect it's the same for others. In any case, setting back to needs review.

OK, it's actually this one: #1587676: Not setting language field

It should be fixed with the latest build in the repository, HEAD at 7.x-1.x. The patch didn't fix anything.

Sure

The 6.x-1.1 version of the module should be available shortly for download. It addresses this issue and adds a few other features/fixes.

For me there's still an error when recalculating. After a fresh module install, recalculation fails with the following error:

Ein AJAX-HTTP-Fehler ist aufgetreten. HTTP-Rückgabe-Code: 500 Im Folgenden finden Sie Debugging-Informationen. Pfad: /batch?render=overlay&id=31&op=do Statustext: Service unavailable (with message) Antworttext: 
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'node-82-0-0-und' for key 'PRIMARY': INSERT INTO {field_data_field_hotness} (entity_type, bundle, deleted, entity_id, revision_id, language, delta, field_hotness_value) VALUES (:db_insert_placeholder_0_entity_type, :db_insert_placeholder_0_bundle, :db_insert_placeholder_0_deleted, :db_insert_placeholder_0_entity_id, :db_insert_placeholder_0_revision_id, :db_insert_placeholder_0_language, :db_insert_placeholder_0_delta, :db_insert_placeholder_0_field_hotness_value); Array ( [:db_insert_placeholder_0_entity_type] => node [:db_insert_placeholder_0_bundle] => proposal [:db_insert_placeholder_0_deleted] => 0 [:db_insert_placeholder_0_entity_id] => 82 [:db_insert_placeholder_0_revision_id] => 82 [:db_insert_placeholder_0_language] => und [:db_insert_placeholder_0_delta] => 0 [:db_insert_placeholder_0_field_hotness_value] => 0 ) in _computed_field_tools_batch_recompute() (Zeile 535 von $DRUPAL_HOME/sites/all/modules/contrib/computed_field_tools/computed_field_tools.module).

I'm using the latest dev snapshot for D7.

Did patch in #4 really go into the code? It doesn't look like to me.

However, as the error occurred in my drupal installation too, it was caused by another thing. When writing back the computed value into the db, we test if the field will be updated or inserted. Here a wrong compare operator is used:

// Query the database if a computed value already exists
$existing_content = db_select($table_name_current, $table_name_current, ...);

// This causes the error, simply because computed values can contain zero values.
if (empty($existing_content)) {
  // use sql-insert -> error
}

Thus, having a zero value in an existing field, we go for inserting because empty(0) returns true. Instead we should write

if ($existing_content === FALSE) {
  // use sql-insert
}

My patch fixes this.

I can confirm bug/error in 7.x-1.0
I can confirm that patch attached in #15 works like a charm - please commit it ASAP and create 7.x-1.1 version.

roball: you are right. my mistake, it was late night here and (i dont know why) i thought that tagging RTBC is enough...

While I agree that this patch works, wouldn't it be better to use db_merge()? In the worst case, it's still doing two queries, but it makes the code simpler and easier to read.

Patch #16 works fine for me. Thanks!

This issue should be solved from 7.x-1.1-rc1 and forth.