order from different user in the list

[Jörgen]

OK, i have mixed your numbers in my head. All the autoincrement values seem ok, let alone you have a little hole in the orders table, but please check joomla user table to.

A user only creates items in the order_userinfos table. BT and sometimes also ST address entries with user_id 0.

Are you sure that there ha been only 2823 orders since 2012 and only 563 registered users ?

Have You deleted orders or users in the past ? This could maybe explain this.

Have You migrated the joomla site, with a migration tool?

Check to see if You have user entries "virtuemart_user_id" in any of the tables that do not correspond to the actual user_id table. e.g user_id == 705. This could mean that you have deleted users in the wrong way and are starting new with user_id that have been already taken.

What are the highest user id in the order_userinfo table ? and what are the latest user_id ?

I wish I could say that there is an easy way to clean up this mess, but all solutions I see involve some detective skills to see the results.

Jörgen @ Kreativ Fotografi

[diri]

Such detective work is rather cumbersome.

MySQL Workbench can be a usefull tool to get an overview about dependancies of tables. It can show you which field in which table depends on which field in another table (referential integrity, 1:n, m:n and so on).

To fix such problems I would export whole DB of installation and import it to a separate local DB. With one eye on structure I would check values in related tables and make notes about how to fix it. Chance is hight to detect more errors not being visible at the moment in live system. When those fixes work local I would sync data with online system.

Be very carefull with this synchonization (double check both DBs before changing something in live system!!) and take care of new entries in live system in case you didn't set it in maintenance mode!

Be aware of the fact that autoincremented values are unique but not necessary higher than existing edit: values   max value in case something has been deleted! One "hickup" of DB at deletion will break integrity without stopping deletion of an important value - you will get such "leaks" in sequence and wrong results afterwards like you have it now.

cu, diri