>
>It's true that DB apps make more extensive use of disk I/O than Word, for example. My point was that write caching is an OS-level service, operating "below the horizon" of applications. Apps can't choose to use or not use write caching - if it's on, they all get it, if it's off, they don't.

Not true. Go buy a Compaq Proliant Server with a disk array. The drive controller has an onboard hardware cache that is NOT controlled by the OS. In fact, you have to down the server and run Compaq setup tools to turn off the cache. This caching has absolutely nothing to do with the OS and works the same whether you are running NT, Netware, or Unix.

>
>The harder any app pounds on the disk subsystem, the more important write caching becomes. File-based databases are by *NO* means the only apps capable of saturating a disk. If there's a problem with write caching with a given controller, it will become apparent just as rapidly with SQL Server or any other type of DBMS.

SQL Server uses different algorithms to update files. While the problems can happen, they aren't as visible.

>
>Disabling write behind caching in modern OSs is very much a case of throwing out the baby with the bathwater.

I have seen cases of index/file corruption disappear when turning off the write cache. It very much can be a problem with file-based systems like VFP.