Naruszenie ograniczenia integralności: 1062 Zduplikowany wpis dla klucza „UNQ_SALES_FLAT_INVOICE_INCREMENT

Pomagam handlowcowi znaleźć podstawową przyczynę niektórych nieudanych transakcji płatniczych (w dniu dużego zamówienia), które zakończyły się błędem z następującym błędem

SQLSTATE [23000]: Naruszenie ograniczenia integralności: 1062 Zduplikowany wpis „51986” dla klucza „UNQ_SALES_FLAT_INVOICE_INCREMENT_ID”

UNQ_SALES_FLAT_INVOICE_INCREMENT_IDIndeks jest unikalny klucz na increment_idkolumnie w sales_flat_invoicetabeli. Kiedy szukam w tej tabeli informacji o increment_idbłędzie ( 51986), stwierdzam, że jest tam już faktura increment_idi dotyczy zamówienia złożonego przez innego klienta.

Moje 2 pytania z tym związane

Gdzie w Magento CE 1.9.0.1 zwykle tworzy się identyfikator faktury?
Czy znane są problemy w magazynie Magento CE 1.9.0.1 z kolidującymi identyfikatorami faktur dla prawie równoczesnych zamówień?

Zdaję sobie sprawę, że identyfikator przyrostu 51986oznacza, że sklep ma jakieś rozszerzenie do zmiany zainstalowanych identyfikatorów przyrostowych, ale chcę się upewnić, że nie ma do tego wiedzy naukowej w / r / t, zanim przejdę zbyt daleko.

— Alan Storm
źródło

Dodanie Mage_Eav_Model_Entity_Type :: fetchNewIncrementId () jako punktu debugowania.

— Alan Storm,

Widziałem to już wcześniej, ale było to spowodowane tym, że ktoś umieścił save()wywołanie metody w konkretnym zdarzeniu obserwatora, co czasami powodowało ten problem - na kilka dni przed przeglądem kodu;)

— Erfan

@AlanStorm, właśnie z ciekawości, dlaczego wchodząc w byt Eav, myślę, że faktura jest płaskim modelem.

— Prateek

Myślę, że może się to zdarzyć również w przypadku domyślnego Magento stackoverflow.com/questions/25918091/...

— Kristof z Fooman

Znam to starsze, ale tabela eav_entity_store została skopiowana z jakiegokolwiek powodu. Jest to częsty błąd, w którym identyfikator ostatniego zamówienia nie zgadza się z aktualnie złożonym zamówieniem. Tak więc Magento używa tabeli eav_entity_store, aby określić, jaki identyfikator należy wstawić do tabeli zamówień, aw tym przypadku już istnieje. Należy również pamiętać, że jest to bardzo częsty problem z rozszerzeniem numeru zamówienia FooMan, ponieważ może on ominąć to sprawdzenie i spowodować, że ten problem zniknie.

— Rob

Zamówienie, faktura, kredyt, wysyłka była EAV do 1.6 (?)

@ Faktura Prateek BYŁA modelem EAV, a increment_id nadal jest.

Increment_id tworzenie i problem

Identyfikator przyrostu jest tworzony tutaj

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

Zakładałbym, ponieważ w ostatniej metodzie transakcja jest uruchamiana (a tabela / wiersz nie jest zablokowana) tworzenie drugiego zamówienia może przejść obok tego samego nowo utworzonego increment_id.

Rozwiązanie

Zakładam, że jeśli zablokujesz wiersz / tabelę przed odczytem, możesz uniknąć tego, że jakikolwiek inny proces odczytuje tabelę, dopóki nie napiszesz nowego parametru increment_id. Może to pomóc: Jak zablokować wiersz po użyciu load ()?

Obawiam się jednak, że zablokowanie szeregu powoduje pogorszenie wydajności.

— Fabian Blechschmidt
źródło

Właśnie zobaczyłem ten post i @Fabian, to dobrze wiedzieć. SE powinna również uruchamiać powiadomienia, gdy ktoś jest wymieniony w odpowiedzi.

— Prateek

Naruszenie ograniczenia integralności: 1062 Zduplikowany wpis dla klucza „UNQ_SALES_FLAT_INVOICE_INCREMENT_ID”

Zamówienie, faktura, kredyt, wysyłka była EAV do 1.6 (?)

Increment_id tworzenie i problem

Rozwiązanie