Sorry but I skipped your below response.

>OK, then why do you blame VFP's "ISAM" tables/.FPTs for this? Hell, we've had reported here, very recently, a problem where some simple external icon-manipulation software interfered drastically with VFP. We've had reports here that VFP gives C000005s when product XXXXXXX is running.
>Sure, you may have "proven" that FPT corruption is related directly to your finger scanning software, but why then extrapolate that to be a general problem with .FPTs??? Why point squarely at VFP at all?

It's a problem with the FPT, the system can't open it rather giving us "Invalid Memo File."

>>My applications have used MEMO fields extensively, albeit in rather simple and benign ways. I have never encountered a corrupted .FPT myself either.
But IMO, out of many users only a few don't have problem with FPTs.

>>Again, after reading "Inside SQL Server 7.0", I think you are fooling yourself with your last sentence above. If you think VFP tables take care in their design and maintenance (to achieve near-optimum performance/stability) I can say that SQL Server takes more care, more often. Not to mention the administrative issues like granting access rights, log administration, statistics review/action, etc. My guess is that surprises are around the corner if that's really how you are handling SQL Server deployments.

Access Rights, Log Administration have nothing to do with technical problems. These are expected tasks to be done but are not surprises and besides you can schedule it at your convenience. Problems with xBase ISAMS gives us surprises at an unexpected time. You will not know if tomorrow your index and fpts are still ok.

>>And SQL Server really gives you this, the way you describe your deployments above? I did 20 years of support in my mainframe life, and I agree about 3am calls being a pain. I had remarkably few in the biggest FPD system I was responsible for.

With 24 hour operations e.g. hospitals, file corruption is a nightmare...