Error (order number replaced with xxx): 

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'xxx' for key 'order_number': UPDATE {commerce_order} SET order_number=:db_update_placeholder_0 WHERE (order_id = :db_condition_placeholder_0) ; Array ( [:db_update_placeholder_0] => xxx [:db_condition_placeholder_0] => xxx ) in commerce_order_commerce_order_insert() (line 870 of sites/all/modules/commerce/modules/order/commerce_order.module).

Same error as here: http://drupal.org/node/1204210 after creating a fresh commerce install and migrating ubercart data from a separate database.

Comments

krisrobinson’s picture

krisrobinson commented

The solution here: http://drupal.org/node/1204210 was to truncate all the tables, which I don't want to have to do after just migrating.

krisrobinson’s picture

krisrobinson commented

I think what the problem was - was that the order_number table imported from ubercart don't match the order_id, and when commerce creates and order # it's using the order_id and incrementing. So what I think I had to do was update the existing order_numbers to match the order_ids...

Tentatively I'll say I fixed it running two sql statements in phpmyadmin to update the commerce_order and commerce_order_revision tables:

UPDATE commerce_order SET order_number = order_id WHERE 1

and

UPDATE commerce_order_revision SET order_number = order_id WHERE 1
reecemarsland’s picture

reecemarsland commented

I've had the same problem. I needed to drop the order_number unique index first before I could manually update the order_number to match the order_id. My worry here is that the Order numbers on the ubercart invoices will now differ to those now in commerce?

leofishman’s picture

leofishman commented

Thanks a lot!!

leo pitt’s picture

leo pitt commented

The solution here also works, and doesn't require overwriting any data: http://www.drupalcommerce.org/discussions/1142/changing-starting-order-n...

In short - set a new auto increment number on the key to something sufficiently high that it will not cause any conflict.

ALTER TABLE commerce_order AUTO_INCREMENT = 1000;

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Needs work

The solution in #5 works best. I had 16,000 orders in my migration so I have set my new figure to start at 20,000 as it will make it easy to determine which orders came from which version of the site.

Is this something that could be done in function complete($entity, stdClass $row) {} ? It seems like it would be an issue every single time.

Setting issue to "needs work" since we're now aware of the cause and just need some code to eliminate this issue forever. I think if as a last step in the migration we just find the last known order_id and then run the alter based on that we could support rolling back without much hassle.

rootwork’s picture

rootwork
he/him
Primary language English
Location 🇺🇸 US-Pacific 🌎 Chinook (Multnomah, Clackamas) & Cowlitz lands 🌹 Portland, OR
commented

The solution in #5 worked for me too; would be great to see this integrated.

Anonymous’s picture

Anonymous (not verified) commented
Issue summary: View changes
Status: Needs work » Closed (works as designed)
shaneonabike’s picture

shaneonabike commented
Status: Closed (works as designed) » Needs work

Hey

I don't think that is clear for folks and after I migrated I also had this issue. Could something be put in the documentation or some code put in the final order migration as you mentioned?

Anonymous’s picture

Anonymous (not verified) commented

It is something site-specific and applies more to the migrate module than this particular implementation of a migration. So if you wanted to update the documentation, I would probably do it there... though you are welcome to create/edit/update documentation for this module.

Anonymous’s picture

Anonymous (not verified) commented

Ran into this issue again. I think it may be worth adding a complete() hook that looks at both the order_number and order_id tables and changes the auto_increment value. One of these columns is set to auto_increment in the db, while the other is not... and guess which one commerce uses? (not the one the db does!)

dwkitchen’s picture

dwkitchen commented
Status: Needs work » Closed (outdated)

See that this was an issue on the 1.x branch so marking as outdated.