Verletzung der Integritätsbedingung: 1062 Doppelter Eintrag für Schlüssel 'UNQ_SALES_FLAT_INVOICE_INCREMENT_ID'


13

Ich helfe einem Händler dabei, die Ursache für einige fehlgeschlagene Zahlungstransaktionen (während eines Tages mit hohen Bestellmengen) zu ermitteln, die mit dem folgenden Fehler fehlgeschlagen sind

SQLSTATE [23000]: Verletzung der Integritätsbedingung: 1062 Doppelter Eintrag '51986' für Schlüssel 'UNQ_SALES_FLAT_INVOICE_INCREMENT_ID'

Der UNQ_SALES_FLAT_INVOICE_INCREMENT_IDIndex ist ein eindeutiger Schlüssel für die increment_idSpalte in der sales_flat_invoiceTabelle. Wenn ich in dieser Tabelle nach dem increment_idin error ( 51986) genannten Produkt suche , finde ich, dass bereits eine Rechnung mit diesem Produkt increment_idvorhanden ist und dass es sich um eine Bestellung eines anderen Kunden handelt.

Meine 2 Fragen bezogen sich darauf

  • Wo wird in Magento CE 1.9.0.1 normalerweise eine Rechnungs-ID erstellt?

  • Gibt es bekannte Probleme in einem Lager Magento CE 1.9.0.1 mit kollidierenden Rechnungs-IDs für nahezu gleichzeitige Bestellungen?

Ich weiß, dass die Inkrement-ID 51986bedeutet, dass der Store eine Erweiterung zum Ändern der installierten Inkrement-IDs hat, aber ich möchte sicherstellen, dass keine wissenschaftlichen Erkenntnisse vorliegen, bevor ich diesen Pfad zu weit gehe.


1
Hinzufügen von Mage_Eav_Model_Entity_Type :: fetchNewIncrementId () als Debug-Punkt.
Alan Storm

1
Ich habe das schon einmal gesehen, aber es lag daran, dass jemand einen save()Methodenaufruf in ein bestimmtes Beobachterereignis platzierte, was manchmal zu diesem Problem führte - in den Tagen vor der Codeüberprüfung;)
Erfan,

@AlanStorm, nur aus Neugier, warum in Eav Entität gehen, denke ich, Rechnung ist ein flaches Modell.
Prateek,

Ich glaube, dass dies auch mit Standard Magento stackoverflow.com/questions/25918091/…
Kristof bei Fooman

1
Ich weiß, dass dies älter ist, aber die Tabelle eav_entity_store wurde aus irgendeinem Grund kopiert. Dies ist ein häufiger Fehler, bei dem die ID der letzten Bestellung nicht mit der aktuell aufgegebenen Bestellung übereinstimmt. Daher verwendet Magento die Tabelle eav_entity_store, um zu bestimmen, welche ID in die Auftragstabelle eingefügt werden soll. In diesem Fall ist sie bereits vorhanden. Beachten Sie auch, dass dies ein sehr häufiges Problem mit der Erweiterung der FooMan-Bestellnummer ist, da diese Prüfung umgangen werden kann und dieses Problem aus heiterem Himmel verursacht.
Rob

Antworten:


3

Bestellung, Rechnung, Gutschrift, Versand war EAV bis 1.6 (?)

@ Rateek Rechnung war ein EAV-Modell und die increment_id ist immer noch.

Increment_id Erstellung und Problem

Hier wird eine Inkrement-ID erstellt

\Mage_Eav_Model_Entity_Attribute_Backend_Increment which calls
\Mage_Eav_Model_Entity_Abstract::setNewIncrementId which calls
\Mage_Eav_Model_Entity_Type::fetchNewIncrementId

Ich würde annehmen, da in der letzten Methode die Transaktion gestartet wird (und die Tabelle / Zeile nicht gesperrt ist), kann eine Erstellung einer zweiten Bestellung vorbeigehen und dieselbe neu erstellte übernehmen increment_id.

Lösung

Ich gehe davon aus, dass Sie, wenn Sie die Zeile / Tabelle vor dem Lesen sperren, vermeiden können, dass ein anderer Prozess die Tabelle liest, bis Sie eine neue increment_id schreiben. Dies könnte helfen: Wie sperre ich eine Zeile nach der Verwendung von load ()?

Ich befürchte jedoch, dass das Sperren der Zeile zu einem schlechten Leistungsverlust führt.


1
Hab gerade diesen Beitrag gesehen und @Fabian, das ist gut zu wissen. SE sollte auch Benachrichtigungen auslösen, wenn jemand in einer Antwort erwähnt wird.
Prateek
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.