>>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.
>
>>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?
>
>The assumption that SQL-server does not suffer from latency. I can run SQL-server on my IDE drive. I don't see why a database server should care of there is a (bit) of latency. In an event of a crash, the transaction log should be used to recover. Whether all the bits are written to the media during the crash is not a major concern. It's only going to recover what is in the Transaction log.
>
Walter,

Provided, of course, that the transaction log is accurate. That's the reason you don't want any latency. Everthing I stated above is from the book "Inside SQL Server 7.0" from Microsoft Press by Ron Soukup and Karen Delaney (both of the SQL Server team) ISBN 0-7256-0517-3. If you have any doubts about the accuracy of my statement, read the book for yourself.