Walter,

Since we've agreed to disagree, I'll address only one of the points you made.

>>In contrast, because SQL server is optimized and written for WinNT/2K it communicates directly (via the API) with the hardware and specifically states that in the instance of the controller caching the writes to get another controller where this can be disableed.
>
>I doubt if this is true. Again the corruption problem generally is solved with
>transaction logs. Solving latency issues with specific hardware communications is maybe nice in performance terms, but add nothing to ensuring a consistent state of the database. when a crash occurs when a transaction is written, the written bytes have to be reverted (to meet the ACID properties) anyways if the whole transaction has not been commited.
>
What in the above do you doubt is true? That SQL Server is optimized for WinNT/2K? Or the statement about the drive controller? Do you realize that in event of failed media in a RAID array that it can re-construct the failed disk on the fly, or do you dount that too?