>I'm not sure such a rigorous regime would be either warranted or needed......
>
>Perhaps that is a cue for somebody to deliver a patronizing "change sometimes involves pain" lecture. ;-)
>
>In the end, any database is just a file or files on a hard drive. Users can come up with numerous innovative ways to screw them up. ;-) I remember one client who complained that a crucial PC with my app kept restarting and losing data. In the end I came and watched the user. A phone on the adjacent desk rang; she leant across to take the receiver and her dainty foot knocked a forest of multipoints and adapters plugged into her single power point. The machine rebooted. ;-) I also had a customer who put a server behind a door in the so-called server room: as I watched, an IT person burst into the room, thumping the door hard against the server. I had a "project manager" who screwed with his PC until his network card was flaky +++: every time he logged into my system, havoc ensued. ;-)
>
>I'd also say that Dbf files can be easy enough to repair. I've done it myself over the years and many vendors supplied automated repair tools. Sql Server mdfs are a different proposition. Anybody here have experience fixing a torn system table page? My expectation would be that even the most decorated practitioners would have limited experience repairing the sort of flake you have to expect on a personal PC. All it needs is a buggy music codec or the user kicking an adapter and you risk an "I can't restore from last week's backup! It's tax time and my accountant needs the new entries TODAY!!" crisis for which the vendor will be blamed. Only a vendor with 95% market share can shrug that off.

In our 11 years in business doing almost exclusively SQL Server based systems, I think I've seen 2 instances of a SQL instance that wouldn't start, requiring a reinstall of SQL Server. One was immediately after a patch Tuesday. The other had just about every version of spyware imaginable on it, and it had Symantec A/V (a virus in its own right). The databases were fine. We had one instance of a database that obviously had something happen to one or more indexes and we had to recreate the indexes.

That's it for problems IIRC.

Most of these SQL installations were on Win 2000 or XP desktops. The rest were on real server hardware.

We do require UPS and A/V on a client machine before we will install an application. We also require that the machine be in stable condition. We have walked off from a couple of potential clients when they refused to meet our requirements.

My last VFP w/VFP tables contract was with the State of Kansas on a major system hosted on major server hardware. Index and table corruption at least weekly. It didn't help that the VFP programs were the worst in human history. I won't work on another system that uses VFP tables. I'll leave them to the people who insist they are OK.