the number of rows should be exact.. every time a wp user is added, a row is added to the sfmembers table…  if you manually added or deleted users instead of through the wp api/ui, then problems can arise…  in sfmembers, there is a pointer (id) to the row within the wp users table…

how many wp users listed on wp – users? 

when you imported the db, was it empty?  ie no existing wp users?

seems like a big mismatch in users which is very problematic…  there are no sp users, only wp users… and we add our ‘extra’ data for the user in the sfmembers table…

so first step is to see which sfmembers tables, dont have a corresponding wp users entry – and vice versa…

Mr Papa said
the number of rows should be exact.. every time a wp user is added, a row is added to the sfmembers table…  if you manually added or deleted users instead of through the wp api/ui, then problems can arise…  in sfmembers, there is a pointer (id) to the row within the wp users table…

how many wp users listed on wp – users? 

when you imported the db, was it empty?  ie no existing wp users?

seems like a big mismatch in users which is very problematic…  there are no sp users, only wp users… and we add our ‘extra’ data for the user in the sfmembers table…

so first step is to see which sfmembers tables, dont have a corresponding wp users entry – and vice versa…  

not sure a query would do it… you would  probably need to write a small php script that looped through the wp users and checked for sfmembers…  and find non matched ones… then repeat for the opposite…

Mr Papa said
not sure a query would do it… you would  probably need to write a small php script that looped through the wp users and checked for sfmembers…  and find non matched ones… then repeat for the opposite…  

ok, what should I do when I’ll find wpusers not included in the sfmembers table and viceversa? 

I am coming late to this topic but it is worth mentioning that if any user tries to access the forum with a WP users record but no sfmembers record – then it will be automatically created at that point with default values.

whats confusing is that its trying to create a new sfmembers row of data, but it already exists… actually, its a duplicate key…  can you check in your db using phpmyadmin or other and show what the indexes are in a screenshot?  something like this

My suspicion arises from the error reports attached in post #10. When a repair operation fails – and I have never seen that happen before – then who knows what could have been written to the DB incorrectly. The table in question was probably in a bad state for quite a while. It seems entirely possible to me that keys have been written to the btree that are not indexed properly (so Mr Papa’s question above is important).