For sure a C/S solution is far more stable. But if you "need" VFP tables for whatever reason, you can have a high level of reliability implementing daily backups and audit tracking. In case something fails, you restore the last backup and build all the transactions from the log tables. Daily backups is easy on non 24/7 applications, and for audit traking there are 3rd party utilities.

>It is over 10 years since I had to recover corrupt local tables. ;-) What I remember apart from the easy header fix is series of records converted to fields full of chr(0), field contents transposed into other fields/records and all sorts of unpredictable behaviors. After checking the header and reindexing from scratch you still need to review rows looking for physical corruption. The concern is that once you have tens or hundreds of millions of records, checking for obvious corruption is not a case of Browse/hit page down repeatedly. ;-) It is a huge job.
>
>If, after you have "fixed" the table the customer then does a report and gets bizarre results because of residual physical corruption (e.g. customers with corrupted non-human-readable content in the cName field, thousands of $ commission allocated to a rep apparently named "~" ;-) ) then customer loss of confidence becomes entrenched.
>
>Moving to C/S does not prevent corruption and if a SQL Server record is physically corrupt you may see lockups merely trying to access it. But they are much less common. A properly maintained C/S database can deliver effectively permanent reliability/availability for years.