«Out of range value for column id_product» al crear productos

Un compañero de la comunidad no podía crear productos nuevos: cada intento daba Out of range value for column 'id_product'. Los últimos productos tenían identificadores correlativos (12176, 12177, 12178) y, de pronto, había uno con el 4294967295. Ese número es el máximo que cabe en la columna, así que el siguiente producto no tiene sitio. La solución es quitar ese producto y devolver el contador AUTO_INCREMENT de la tabla a su sitio; borrar el producto, solo, no basta.

El error

Out of range value for column 'id_product' at row 1
INSERT INTO ps_product ...

No podía volver a una copia de seguridad porque desde entonces se habían hecho ventas. Probó a borrar el producto raro y a cambiarle el identificador en la base de datos, y seguía igual. Otro miembro del grupo le dio la pista: modificar el AUTO_INCREMENT.

Qué ha pasado

La columna id_product es un entero sin signo de 32 bits: su valor máximo es 4.294.967.295. MySQL y MariaDB dan a cada fila nueva el valor del contador AUTO_INCREMENT de la tabla, que siempre queda por encima del identificador más alto que haya habido. Cuando algo inserta un producto con el identificador máximo, el contador ya no puede subir y cualquier inserción falla.

Por eso borrar el producto no arregla nada: el contador se queda donde estaba, más allá del máximo.

¿Quién mete un producto con ese número? Casi siempre un proceso que no es el back-office: un importador, un conector con un ERP o un marketplace, o un script que envía un identificador al crear en lugar de dejar que lo ponga la base de datos. Si la base de datos no está en modo estricto, un número demasiado grande no da error: se recorta al máximo y se guarda.

Cómo arreglarlo

1. Haz una copia de la base de datos.
2. Localiza los productos con identificadores fuera de lo normal:

   SELECT id_product, reference, date_add
   FROM ps_product
   ORDER BY id_product DESC
   LIMIT 10;

3. Si ese producto no tiene ventas, bórralo desde el back-office, no con SQL: así PrestaShop limpia también sus filas en las tablas relacionadas (idiomas, tiendas, stock, imágenes…). Si tiene ventas, apunta su referencia y sus datos: tendrás que volver a crearlo con un identificador normal, y las líneas de pedido antiguas seguirán apuntando al viejo. En ese caso, mejor que lo mire alguien con experiencia.
4. Devuelve el contador al siguiente identificador libre. Con el producto ya borrado:

   SELECT MAX(id_product) + 1 FROM ps_product;
   ALTER TABLE ps_product AUTO_INCREMENT = 12179;

   Pon el número que te dé la primera consulta. Si pones uno menor o igual que el máximo existente, MySQL no lo acepta tal cual: lo deja en el máximo más uno.
5. Crea un producto de prueba y comprueba que recibe el identificador esperado.

Revisa las demás tablas

Si un proceso metió un identificador disparado en ps_product, puede haberlo hecho en otras. Esta consulta solo lee y te dice qué tablas tienen el contador sospechosamente alto:

SELECT TABLE_NAME, AUTO_INCREMENT
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND AUTO_INCREMENT > 100000000
ORDER BY AUTO_INCREMENT DESC;

Mira sobre todo las que toque el mismo proceso: combinaciones (ps_product_attribute), imágenes (ps_image), características…

Encuentra al culpable

Si no corriges el origen, volverá a pasar. Mira qué importaciones o sincronizaciones se ejecutaron justo antes de la fecha de alta del producto raro (date_add) y revisa si ese proceso envía un identificador al crear productos. Al crear, el identificador lo pone la base de datos; el proceso solo debería usarlo para actualizar productos que ya existen.

Si te ha pasado y no lo ves claro, en Rekire lo resolvemos dentro de nuestros bonos de horas.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación