>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.

Ouch! 200 tables ? Sounds like a trouble maker. No wander why you got problem.

>
>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.

I agree that FPD (and all dos xbase) had such issues but at least for fox
all that changed from VFP5 for much better. But that is for those who invested effort to apply new data saving/handling possibilities (buffering/transactions). So if you had to deal with fpd apps just compiled to VFP still using bunches of free tables, then yes of course you must hv been seing lot of index/table etc corruptions and I can understand your frustration.

Real RDBMS of course resolves such issues by doing data by itself and by enforcing it's 'rules of engagement'. Developer simply does not get chance to mess up anything :) From that aspect yes, on overall, data are more secure this way.

App you are dealing right now, is yet another extreem. It is probably very problemattic design and will lead to yet more frustration, for as long as you are involved with it. (I had these kind of 'pleasures' in the past)
But that has nothing to do with language/tool but more with ways original authors did it.
This does not mean, that you cannot write rock stable data handling
with VFP native data. If you manage do that, then you get to rip benefits of dealing with extremely fast native VFP data and menu other goodies that comes with it.