George,

>>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.

>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.

I don't have any doubts about the technical statements you made. I have, however, doubts about the importance of handling latency in a Transaction log based DBMS. Maybe the SQL-server team have explained in that book why it is, but even when the data in the transaction log is a victim of latency, it only means that there is a chance that the latests transaction(s) that have been commited cannot be rolled forward. In general the latency is about a fraction of a second, so even when the database crashes the chance of an interrupted transaction log due to latency is small, especially for DS systems, where SQL-server is positioned.

Walter,