>"can be more difficult to recover". Hmm... That's converning, because I have had a few instances where some of my dbfs will get junked up with some "Table Has Become Corrupted" error, and I use a prg that I found somewhere that fixes up the file header with some pretty low-level code to make it work again. Always scary, but so far, it has worked every time.
>
>So, since that prg messes with the dbf file like that, I guess it's possible that it could break the linking between the file and the dbc.
>
>Can you elaborate on any problems you've had or know of, and what the actual remedy is/was?

Simple table header issues are never a problem for tables in a .DBC

Here are some things I've run into:
1. The table appears fine but there is a problem with the DBC, but VALIDATE DATABASE RECOVER has issues with the table. So
you have to hack the .DBC to remove references (index, etc) so you can validate the database so that you can recover the table.

2. The table is really FUBAR'd and removing it (temporarily) from the datbase to make recovery life easier results in all your long field names now truncated to 10 characters, even if you reattach it.

3. Primary Key enforcement from the .DBC on a table which has become corrupt can make recovering the table more difficult.

I've run into other scenarios too which the .DBC makes harder. Invariably, with this really FUBAR data, the customer was using Wi-Fi which we always tell them not to do, but they do anyway.


Obviously all these issues go away if the database is MS SQL, MySQL, etc.