I am not surprised you are not finding duplicates by browsing on another machine. This is what is supposed to happen. Records attempted to be added that duplicate a PK are rejected and not allowed to be inserted. YOu need to look at how you are populating your PK field. If it is initially zero, look for another record [deleted or not] that has this ID. Also make sure the way you generate PKs is not looking for the last used PK in the table because if you have deleted records, you may have a deleted record with a PK that comes after the last non-deleted record. The exception to this is if you have a filter on your PK index expression that includes NOT DELETED().

I use a separate KOUNTERS table that keeps track of my last used PK for all my tables.

I have no explanation as to why the existing records are being trashed.

>Thanks for your input guys but - In the past I though I had a way with words but it seems now that I deal only with 'if this then not that' I have a hard time writing clearly. Let me retry. Both machines had the same table (same # of rec with same data) with the same data. Machine A ( test machine ) when running the stonefield repair proc, reported 'Duplicate index key'. This more or less crashed my app. When I came back to the development machine ( Machine B and completely independent of machine B), I was able to open the same table and able to determine that there was NOT a duplicate on the primary key ( no deleted records and no matching records). I then ran the app on machine B and sure enough when the stonefield repair proc was run (oMeta.Osdtmgr.Repair('ALL')) I got the same error. When I went back to the command window the DBF was trashed. It was in good condition before I ran repair. This scares me somewhat and I would like to know what happened.