Troubleshooting

PrestaShopException: diagnosing Invalid address

Reviewed on 3 min read base de datos errores prestashop

The Invalid address #ID exception means PrestaShop could not load a valid address for that identifier. The stack trace tells you whether it comes from a cart, an order or a module; don't assume every case is fixed by setting an address to zero.

Find the reference

Note down the ID, action, URL and stack trace. Work on a copy first. Replace PREFIX_ with the real prefix and <ID> with the number you have checked:

SELECT id_address, deleted, active
FROM PREFIX_address
WHERE id_address = <ID>;

SELECT c.id_cart, c.id_address_delivery, c.id_address_invoice, o.id_order
FROM PREFIX_cart c
LEFT JOIN PREFIX_orders o ON o.id_cart = c.id_cart
WHERE c.id_address_delivery = <ID>
   OR c.id_address_invoice = <ID>;

If the address exists, check its status and the logic that uses it before changing it. If there is an order, preserve its historical address; a reference that doesn't exist may need to be recovered from a backup and the order's integrity checked.

Limited case: cart with no order and a missing address

Only when the stack trace confirms this case, identify one specific cart and the affected field. This example affects only the delivery address of the selected cart, which has no order and whose address doesn't exist. Also replace <ID_CARRITO> (the cart ID):

START TRANSACTION;

UPDATE PREFIX_cart c
LEFT JOIN PREFIX_orders o ON o.id_cart = c.id_cart
LEFT JOIN PREFIX_address a ON a.id_address = c.id_address_delivery
SET c.id_address_delivery = 0
WHERE c.id_cart = <ID_CARRITO>
  AND c.id_address_delivery = <ID>
  AND o.id_order IS NULL
  AND a.id_address IS NULL;

SELECT id_cart, id_address_delivery, id_address_invoice
FROM PREFIX_cart
WHERE id_cart = <ID_CARRITO>;

ROLLBACK;

The dry run needs transactional tables such as InnoDB and the same connection for every statement. Confirm that only the intended row changes and that ROLLBACK restores the previous value. It is no guarantee of rollback on MyISAM.

To check how the application behaves, commit the change only on the clone and reproduce the cart there. A web request on another connection won't normally see your transaction's uncommitted changes yet. The customer may have to select their address again.

If the wrong field is the invoice address, prepare and test the corresponding statement; don't change both out of habit. In production, keep another backup taken immediately beforehand and avoid concurrent writes before running only the change you have tested. Don't empty carts or normalise every orphaned reference in the shop.

If you can't identify a single relationship and its effect, give the stack trace and the identifiers to support or to the developer, without attaching personal address data.

You may also find useful

Something wrong or out of date? Tell us and we will review it.