Chris,

The following may be of interest...
Re: Header corruption and KB Q293638 Thread #580276 Message #583143

Re: Header corruption and KB Q293638 Thread #580276 Message #583677
...maybe even the whole thread.

Some of it speaks to a corrupted table when there are integer PKs and suggests that a workaround is to put a dummy INT field and a dummy C(10) field at the start of the table.
Not answering your question, but maybe helpful fo the future.

good luck



>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.
>
>I'll document it and post it in the articles for others to use once I figure it out.
>
>Thanks,
>Chris
>
>>Chris,
>>
>>You aren't going to find any such documentation on the binary content memos. Why can't you use an ALTER TABLE command to drop the PK?
>>
>>>I'm looking for some documentation on the structure of the properties field in a DBC file. MS provides some limited documentation in the FILESPEC directory on a standard installation, but it does not provide much info. It references "codes" in the property field, and I can examine the binary data in the property field and match up some of the codes, but documentation would be very helpful.
>>>
>>>Specifically, I'm trying to remove primary keys from tables by modifying the DBC directly (modifying the property field of the table and index entry in question), rather than using the SQL modify commands. For technical reasons I can't use the SQL commands in this particular case.