Chris,

Ok that explains the problem better. Go with what Doug says in another reply in the thread.

>We have a vertical market app with 100's of installations and every once in a while a table will get corrupted and have multiple duplicate primary keys (actaully, the pk field has become all nulls for multiple records), therefore, VFP won't open the table via a USE. The ALTER TABLE command also fails with a primary key prop invalid error. Using normal means the only option in VALIDATA DATA RECO which is unavailable in a VFP 6 exe. However, if we remove the primary key reference from the DBC we can open the table and delete the bad records, then re-add the primary key reference and everything is fine.
>
>The current procedure is connect to the customer via PCA and drop a manually modified database container (where the pks were dropped) into the data directory. This lets us open the table via a standalone browse program and delete the bad records manually. Finally, we put the correct DBC back and everything works. We can't download the tables to our location for repair, they're much too large.
>
>However, I've identified the bytes in the property field of the DBC that control the primary key (for the table and index entry) So I can write a standalone utility that will remove the primary key, delete any bad records, then restore the primary key (backing up the data before of course) With this utility we can automate maybe 90% of our data repair support calls, and the rest we'll still have to do manually. I wanted some docs on it to make sure I was doing it right, but obviously it can be reverse-engineered by adding and dropping the key and comparing before and after.