I know that a DBC is a data dictionnary. But it can also contains RI code and custom code. So that code can be lost if the DBC goes bezerk. I had also a couple of tables that refuses to open and link to the other DBC that I got from the backup. Had to erase and recreate the index file to fix the problem. So I guess from what you are implying that I am doing some wild day to day development.

The DBC contains about 200 tables, so creating one from scratch didn't enchant me very much.

Now, I know that there should be a better backup strategy here, but I'm here only for a short term contract and I thought at first that the data folder was taken in the backup. I had the unpleasant surprise this week to know that this is not the case.

I've been developping in FD/FPW/VFP since 1990 and I've given up counting the number of times a corruption occured in a table, an index file, a memo file or a database file. I had used SDT in some places and it was a real help, but you won't find a similar tool for SQL Server simply because it's not needed. I *never* had a corruption problem with SQL Server.

>You had corruption on DBC container. DBC container is data dictionary (data about data) so unless you are running some wild day to day development (structure changes) ANY previous copy will normally do.
>Did you loose actual data ?
>
>I saw this once but on someone else app. They had over hundred of tables with PR/RI triggers within single DBC. But If you keep data divided into moderate size DBC containers (as per some logical role in overal design) you will not see this happening a lot if ever.
>
>I don't believe I am lucky. I foster literally hundreds of VFP databases (MultiModule/Company/Year) at multiple site installations. And NEVER had such problem. But I never designed single database container holding more then 25 tables nor ever updated actual data records outside buffering/transaction band. This simply works.