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

13

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.

magento-1.9 orders mysql invoice Alan Storm
źródło
1
Dodanie Mage_Eav_Model_Entity_Type :: fetchNewIncrementId () jako punktu debugowania.
Alan Storm,
1
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
1
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

Odpowiedzi:

3

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
1
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