Infracción de restricción de integridad: 1062 Entrada duplicada para la clave 'UNQ_SALES_FLAT_INVOICE_INCREMENT_ID'


13

Estoy ayudando a un comerciante a rastrear la causa raíz de algunas transacciones de pago fallidas (durante un día de pedido pesado), que fallaron con el siguiente error

SQLSTATE [23000]: violación de restricción de integridad: 1062 Entrada duplicada '51986' para la clave 'UNQ_SALES_FLAT_INVOICE_INCREMENT_ID'

El UNQ_SALES_FLAT_INVOICE_INCREMENT_IDíndice es una clave única en la increment_idcolumna de la sales_flat_invoicetabla. Cuando busco en esta tabla lo increment_idmencionado en el error ( 51986), encuentro que ya hay una factura con esto increment_idallí, y es para un pedido realizado por un cliente diferente.

Mis 2 preguntas relacionadas con esto

  • ¿Dónde en Magento CE 1.9.0.1 se crea normalmente un ID de factura?

  • ¿Existen problemas conocidos en un stock Magento CE 1.9.0.1 con identificaciones de facturas colisionantes para pedidos casi simultáneos?

Me doy cuenta de que la ID de incremento 51986significa que la tienda tiene algún tipo de extensión para cambiar las ID de incremento instaladas, pero quiero asegurarme de que no se conozca ciencia con respecto a esto antes de ir demasiado lejos en ese camino.


1
Agregar Mage_Eav_Model_Entity_Type :: fetchNewIncrementId () como un punto de depuración.
Alan Storm

1
He visto esto antes, pero se debió a que alguien realizó una save()llamada al método en un evento de observación específico que a veces causaba este problema, en los días previos a la revisión del código;)
Erfan

@AlanStorm, solo por curiosidad, por qué entrar en la entidad Eav, creo que, Factura es un modelo plano.
Prateek

Creo que esto también puede suceder con Magento stackoverflow.com/questions/25918091/…
Kristof en Fooman el

1
Sé que esto es más antiguo, pero se copió la tabla eav_entity_store por alguna razón. Este es un error común, donde la identificación del último pedido no coincide con el pedido realizado actualmente. Entonces Magento usa la tabla eav_entity_store para determinar qué ID insertar en la tabla de pedidos, y en este caso ya existe. Además, tenga en cuenta que este es un problema muy común con la extensión de número de pedido de FooMan, ya que puede omitir esta verificación y causar este problema de la nada.
Rob

Respuestas:


3

El pedido, la factura, la conmemoración del crédito y el envío fueron EAV hasta 1.6 (?)

La factura de @Prateek FUE un modelo EAV y el increment_id todavía lo es.

Increment_id creación y problema

El ID de incremento se crea aquí

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

Supongo que porque en el último método se inicia la transacción (y la tabla / fila no está bloqueada) puede pasar una creación de segundo orden y tomar la misma recién creada increment_id.

Solución

Supongo que si bloquea la fila / tabla antes de leer, puede evitar que cualquier otro proceso lea la tabla hasta que escriba un nuevo increment_id. Esto podría ayudar: ¿Cómo bloqueo una fila después de usar load ()?

Pero me temo que bloquear la fila hace que se pierda el mal rendimiento.


1
Acabo de ver esta publicación y @Fabian, es bueno saberlo. SE también debe activar notificaciones cuando alguien se menciona en una respuesta.
Prateek
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.