>Hi George,
>
>SNIP
>>
>>I don't think that the wish is feasible. I'm not the one who rated it, BTW. For performance reasons, any file server is probably going to cache its data. Further, as mentioned in "Inside SQL Server 7.0", some controllers will lie, and not actually commit the data, but simply say so. That's why they tell you to: Make sure that the controller doesn't "lie"; and turn-off write-behind caching.
>>
>>Under the circumstances, I don't think that the wish is feasible, since, when write behind caching is enabled, there's no way for VFP to force the write.
>
>I agree that write behind cacheing and the incumbent lies that it tells the OS is indeed a problem. But we can, and most of us do, turn that OFF.
>
>The problem is what was described in MSKB #Q281281 - that "Windows NT 4.0 and Windows 2000 operating systems seem to perform the FLUSH commands faster because they cache the FLUSH commands and then return operation to the application. (The operating system continues to issue FLUSH commands in the background.)" (italics are mine). This effectively means that the modern OS' are themselves telling a lie, by returning (implying that the FLUSH has been DONE) when it has YET TO BE DONE)!!
>It is THIS that I solicited a change for - to be optionally able to insist that the FLUSH be CONFIRMED before proceeding.
>
>Do you still think that's impossible?
>
Yep, the controller may be lying. That's where the problem is. Not only does it have to allow you to disable write behind caching, but it can't "lie" about what its done.