Something happened in Evo and we have a part L521-G that at the DB level is in the MTICMSTR and BKICLOC table, but missing from the BKICMSTR. In our test company
trying to re-add it to the BKICMSTR table (using MDB, just the part #)  going into IN-B and attempting to add it or have it re-create itself does not work.  In fact, in IN-B (or IN-A), typing in the part # brings up a completely different part #!  WT?  We tried to delete the different part # in the test company via MDB (it's obsolete) and it displays an error  wtasdatam.src line 1090 and says there is no active record in the table so you cannot delete it. We click on OK.  The error goes away.  We go into IN-A or IN-B and it still insists on bringing up the different part #, so we cannot create the part #.  
 
We have orders we need to fulfill for the L521-G part and need help figuring out how to fix or at least get around this.  They also tried copying the base part L521 to a new part L521-G and when you click on OK to create the part that darn different part # shows and a message comes up and tells us the part # already exists in inventory.  ?????  
 
HELP!!!
 
Val

So do you mean delete from BOTH tables before trying to re-add?  We can try that in our test company.
 
We are seeing that this may be an index or key issue as there are other things going on.  Specifically, when in IN-A and in the list or lookup mode, scrolling thru the records seems to "loop", getting to a certain point in the table and then the records seem to jump back to a previously scrolled by record.  It happens at different points in the lookup list.  Also, running SM-J-C seems to do that same thing, getting stuck at one point in the process and staying there forever.
 
Would this be a index or key issue, and if so how do we fix that? There are no reported Btrieve errors, corruption or otherwise, in the log files.
 
Anybody?  We are getting more desperate here, it's killing us.

OMG spoke too soon.  
 
Holly just went to run an inventory report (in-f?) and she's getting errors "unable to find the BKICMSTR record" for many parts.  This didn't work at all.  
rolling back to  a backup.    Not sure why a reindex would cause this mess!!!
 
Anybody had this happen before?  
 
What a mess

FYI for anyone reading this:  the actions resolved our issue, with one change:.  Walter suggested SM-J-C report mode B and clearly that was not correct after we reviewed his report. So we had him run SM-J-C report only for A mode, and that was correct. Ran that for real and once done reviewed the report, looked good according the manufacturing and finance.  Holly ran UT-K-G and did an inventory reconciliation, and that also showed things were back to normal and numbers correct for parts.  Only 2 missing parts that were just added after the date of the restored BKICMSTR file needed to be re-added.
 
Everyone is in agreement we are in good shape, so hopefully we have not missed anything else that should have been done!
 
FWIW, sharing this in case anyone else runs into the same thing in the future.
 
Val