>Two things...
>
>1) I think (quite sure) that Vlad is referring to HD controller cache, and I think that there is NO control other than "on/off" from software for that.

I was responding to the phrase: "ANY caching ..."

MS seems to be referring to "buffers" as "cache" ("an intermediate storage mechanism"), and the process of "caching" as "buffering". At the same time, MS is very specific about when it is actually talking about "onboard" or "drive" (ie. "HD controller") caches.

It is obvious to me that I am able to write "through the cache" on the server (as MS puts it) from a client machine using FILE_FLAG_WRITE_THROUGH (just like SQL Server does).

>
>2) I'm assuming that you are quoting from some MS document in your post. Assuming so...

Yes ... many documents. I've made reference to the FILE_FLAG_WRITE_THROUGH flag previously ... without much impact.

>a) I wonder what "without being buffered. The data is cached..." is actually telling us?

"Beyond" FILE_FLAG_WRITE_THROUGH (FFWT), there is FILE_FLAG_NO_ BUFFERING (FFNB), which means:

The FILE_FLAG_NO_BUFFERING takes this concept one step further and eliminates all read-ahead file buffering and disk caching as well, so that all reads are guaranteed to come from the file and not from any system buffer or disk cache.

I take from this that FFWT still user "buffers", but does not "buffer" in the "classic" sense; ie. the data does not sit in the buffer for some period of time before getting written to disk; it is immediately written to disk.

HOWEVER, it remains in the "cache" (ie. file buffer) on the Server, so that subsequent "reads" can be satisfied from the cache with having to go to the HD.

Contrast this with FFNB, where there is NO "caching" at all and all reads and writes go directly to the HD (where, of course, the data could still be sitting in the "onboard" or "drive" cache). This is obviously NOT what WE want ... for performance reasons.

>b) There is still something amiss, and I assume it is in the description and not the actual operation. It is logically incorrect to make the cached record(s) READable when it has not yet been WRITten to the file. If I were guessing I would say that the successful WRITE return causes the cached record(s) to become READable from cache.

There is something amiss if you assume file operations in the absence of FFWT: processes are "reading" from a cache that has not been "written" (to HD). And perhaps, they are even "updating" this cache. It's like writing and reading a VFP "in-memory" cursor.

(IMO) A FLUSH that "worked" or FILE_FLAG_WRITE_THROUGH, would eliminate this scenario: "reading", without "writing" to HD first.

I think the "answer" is a 2-parter:

1) VFP should open all files with FILE_FLAG_WRITE_THROUGH
2) The FLUSH should initiate the "Write" (when VFP has not done so already)

In this way, there is still some level of "write buffering" going on at the Client level.