Порушення обмеження цілісності: 1062 Дублікат записи для ключа "UNQ_SALES_FLAT_INVOICE_INCREMENT_ID"


13

Я допомагаю продавцеві відстежувати першопричину деяких помилкових платіжних операцій (протягом великого дня замовлення), які не вдалися із наступною помилкою

SQLSTATE [23000]: Порушення обмеження цілісності: 1062 Дублікат запису "51986" для ключа "UNQ_SALES_FLAT_INVOICE_INCREMENT_ID"

UNQ_SALES_FLAT_INVOICE_INCREMENT_IDІндекс являє собою унікальний ключ на increment_idколонці в sales_flat_invoiceтаблиці. Коли я дивлюся в цю таблицю на increment_idзгадку про помилку ( 51986), я виявляю, що там вже є рахунок-фактура з цим increment_id, і це для замовлення, зробленого іншим клієнтом.

Мої 2 питання, пов'язані з цим

  • Де в Magento CE 1.9.0.1 зазвичай створюється ідентифікатор рахунка-фактури?

  • Чи існують відомі проблеми на складі Magento CE 1.9.0.1 із збіжними ідентифікаторами рахунків для майже одночасних замовлень?

Я усвідомлюю, що ідентифікаційний приріст 51986означає, що в магазині є якесь розширення для зміни встановлених ідентифікаторів приросту, але я хочу переконатися, що до цього невідома наука з / г / т, перш ніж піти занадто далеко вниз по цьому шляху.


1
Додавання Mage_Eav_Model_Entity_Type :: fetchNewIncrementId () в якості точки налагодження.
Алан Шторм

1
Я бачив це раніше, але це було пов’язано з тим, що хтось робив save()виклик методу в конкретному події спостерігача, що іноді спричинило б це питання - за дні до перегляду коду;)
Ерфан

@AlanStorm, просто з цікавості, навіщо входити в об'єкт Eav, я думаю, рахунок-фактура - це плоска модель.
Prateek

Я вважаю , що це також може статися з по замовчуванням Magento stackoverflow.com/questions/25918091 / ...
Крістоф в Fooman

1
Я знаю це старше, але чи таблиця eav_entity_store була скопійована з будь-якої причини. Це поширена помилка, коли останній ідентифікатор порядку не відповідає поточному розміщеному порядку. Тож Magento використовує таблицю eav_entity_store, щоб визначити, який ідентифікатор потрібно вставити в таблицю замовлень, і в цьому випадку він вже існує. Крім того, зауважте, що це дуже поширена проблема із розширенням номера замовлення FooMan, оскільки це може обійти цю перевірку і вивести цю проблему не в синьому плані.
Роб

Відповіді:


3

Замовлення, рахунок-фактура, кредитна пам'ятка, доставка була EAV до 1.6 (?)

Рахунок @Prateek БУДЬ модель EAV, а приріст_id все ще є.

Створення та проблема Increment_id

Тут створено ідентифікатор збільшення

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

Я би припустив, що в останньому методі транзакція починається (а таблиця / рядок не заблокована), створення другого порядку може пройти повз та прийняти те саме новостворене increment_id.

Рішення

Я припускаю, що якщо ви заблокуєте рядок / таблицю перед читанням, ви можете уникнути того, що будь-який інший процес читає таблицю, поки ви не напишете новий додаток_id_id. Це може допомогти: Як заблокувати рядок після використання load ()?

Але я побоююся, що блокування рядків призведе до поганих втрат продуктивності.


1
Щойно побачив цю публікацію і @Fabian, це добре знати. SE також має викликати сповіщення, коли когось згадують у відповіді.
Prateek
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.