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


George,

I'm not sure whether you are referring in the above to my expressions earlier (about Novell vs. NT). If not, try to find it (early hours today).
Further, in that expression I thought of mentioning the cacheing of FPD as by you referred to right now; this was already there in FoxBase, and I think in FPD 2.0 the REFRESH TO n,N (second parameter) started being there, fully operable (learned from the Fox Software guys back then). One thing I know for sure :

We have an app in FPD 2.5 very well documenting all of the cacheing behaviour (some 10 years ago). It was just over two years ago that I encountered a difference in the behaviour of indexes (and cahcheing etc.); I don't know when this change really happened, but I assume in some client-version of Novell.
Another thing is, that we ourselves use MS-client on Novell (5.x) server, and that the behaviour on indexes is the same right now as it already was two years ago. This behaviour is encountered as negative i.e. "not so decent" or however to explain this in one line (I don't mean unstable).

So, what you do with the answer I don't know, but things have DEFINITELY changed, though not in the existing Fox-box of course. But our world is more complex nowadays.

Cheers,