>>>First, "latency" is not in the Index at all, so I assume that you are referring to various between pages 132 - 146.
>>>
>>>In those pages I didn't find anything stating that "it communicates directly (via the API) with the hardware... " but I don't think that that is a problem. However, I can't quite figure what you mean with the words following those - "...and specifically states that in the instance of the controller caching the writes to get another controller where this can be disabled". If you are referring to the line at the bottom of pp 145 to top of 146 that says:"...you should disable write-back caching of the controller or use a different controller." then this is a little different that what you say. This says that these are MY responsibilities, not SQL Server's.
>>
>>Actually, this statement occurs earlier. Page 102 "SQL Server always opens its files by instructing the operating system to write through any other caching that the operating system might be doing." In simplest terms it uses the FILE_FLAG_WRITE_THROUGH constant in the dwFlagsAndAttributes parameter when opening the file. See CreateFile() in the Platform SDK.
>
>OK, that covers the API question, which I said I thought was immaterial anyway. I suppose that VFP could (does?) do this also.

The question is would another operating system, such as Novell, respect it? That answer we don't know. Further, I also have doubts on VFP doing it in the first place. Through FPW 2.6, Fox did its own internal caching of reads and writes. Has this changed? I can't definitively answer that question. However, unless some authoritative source says that it has been changed, I must assume that it hasn't. The internal caching was done for performance reasons. Since there's been no out cry that it's degraded since that time, I must work from that supposition. So, from my POV, this represents an additional factor in the latency problem.

>>>More importantly though, just because this stuff is written in a book called "Inside SQL Server 7.0" does not mean that these things are exclusive to SQL Server. A VFP application and/or a Novell File-Server will make equally good use of a controller that is endowed with the stated feature (guaranteeing I/O completion to media even after a system failure).
>>>It also states that disabling write-caching should be perfectly acceptable in all but the most special circumstances, causing only marginal performance degradation.
>>
>>>Finally, this whole write-up has to do with failure of the system (power or software or otherwise) necessitating a re-boot.
>>
>>So?
>
>Why did you bring it up, then reiterate it? looked like you were saying that SQL Server is special. I'm trying to show that it isn't, in terms of caching.

Fox doesn't currently maintain a transaction log as SQL Server does to allow recovery. That isn't a significant difference?