>The only part of my paragraph not strictly true was the "OS-level" reference. You're right, the controller (whether Compaq, Mylex, Adaptec etc.) can effectively work at the hardware level. However, this merely reinforces my point, which is that applications can't choose whether they want to use write caching or not.

I never said that applications can choose that or not.

>
>It does not matter what type of algorithm is generating disk writes. As far as the disk subsystem is concerned, it's asked to write information to sectors and tracks. Also, I fail to see how corrupted SQL Server data is any less serious than corrupted VFP data.

The transaction log compensates for much of the problem. I'm not saying you won't see it in SQL Server. I'm saying that it is less likely to be seen. SQL Server is much more fault tolerant. It is meshed more with the OS.

>
>As I've said before, if it's a problem with file-based DBs like VFP, it's a problem for the entire system and all its apps, period.
>
>If you've actually made problems disappear by disabling a write cache, then you've fixed a symptom, not the problem. A better solution would have been a firmware update to the drive controller and/or OS disk driver update (if applicable).

Nope. Brand new server, controller, drives, etc and latest firmware and OS patches.

>
>Fact is, as CPU speeds increase, so does the disparity between silicon and disk performance, and the importance of write-behind disk caching.