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.