Hi Jim,
Thanks, this problem has been driving me mad (and probably everyone else) for years, the major problem now is that the winapi call is also cached which still exposes us to the erratic nature of the cache logic, it should be an external EXECUTIVE Call i.e. FLUSH it & FLUSH it now !, Don't wait until you get around to it.
If the same logic was used in PLC's there would be smashed equipment everywhere, when I tell the OS to do something and it returns .T. I expect it to be done, not sometime in the near future.

Regards N Mc Donald

P.S. Just remember, in a default install we are dealing with both the Workstation & Server caches. i.e. double trouble.

>I don't think you're missing anything Neil...
>
>The write cache is totally independent of FlushFileBuffers in the sense that it is strictly a hardware thing. And it is also my experience that it must be disabled to assure clean data. (I also believe that there is buggy code in the OS as regards the hardware write cache being enabled and interpretation of return codes from the hardware.
>
>The FlushFileBuffers is a software (API) implementation that supposedly works in conjunction with Windows' cacheing mechanism to ensure proper data continuity/accuracy.
>FP's original implementation apparently used it (or its earlier cousin) to purge ALL buffered changes in all files. Later versions of VFP seem to have changed that to use some API function that simply 'informs' Windows of the 'readiness' of buffers for purging and leaves the purging to the OS.
>VFP9, apparently, restores the original method with the added twist, at least based on syntax described by FabioL, to allow us to specify the table involved. I have yet to install the beta myself, so I don't know what the Help actually says on the matter.
>But as I see it the control is now back in our own hands, and we can choose if we wish to pay the penalty of frequently flushing data (which assumedly can be lessened by having control over specific tables) FOR SURE versus continuing to let VFP tell Windows to do so at its own convenience.
>
>All in all, though, I find the whole area of cacheing AS IMPLEMENTED IN (recent) WINDOWS to be way overly complex, so much so that there just have to be holes in the code. How they feel they have covered the permutations of various conditions that can occur between local/redirector/actual/other-user in concert with settings for such that may exist on the different systems involved is beyond me. I think they got far too ambitious with it. When it works well it works wonderfully, but when it is malfunctioning there is no way to isolate it as the problem. Ideally Windows would offer user selectable choices for 'levels of cacheing/buffering' and inform us when settings on networked systems might be in conflict with each other.
>
>cheers
>
>
>cheers
>
>>Hi Jim,
>> As recent as last Wednesday I had to disable Write caching on a W2K SP4 network, installed by others, to get stability in our VFP7 app. I had instructed the installers to implement the changes but they hadn't. We do use FLUSH in all our app's, but it doesn't work, disabling caching is the only way I have found to gain stability.
>>
>>Am I missing something.
>>
>>Regards N Mc Donald
>>
>>>Neil,
>>>
>>>This message - Re: Flush why not flush? Thread #748117 Message #748746 - and a few others in the thread clarify somewhat the operation of the API function.
>>>
>>>As I read it, it *can be* "single file aware" but that still is "file" so and USE AGAINs are included too.
>>>
>>>cheers
>>>
>>>>Hi,
>>>>From the testing I did a few years ago the FlushFileBuffers API, it was not single file aware i.e. it flushed the whole cache to disk, and caused a large performance hit. Has this changed ?
>>>>
>>>>
>>>>>>I was serious :-) Really. Knowing Jim's extensive research on the subject, I thought he'd be delighted. Makes one wonder why it was done any differently in the past...
>>>>>>
>>>>>>Let us know how the testing goes. The MSDN library isn't very revealing on the matter.
>>>>>
>>>>>The help says FLUSH now calls the FlushFileBuffers API function... like you say, if it wasn't doing this before, exactly what WAS it doing?
>>>>>
>>>>>If by MSDN Library you're referring to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/flushfilebuffers.asp then yeah, it's not too enlightening.
>>>>>
>>>>>I think ultimately it has to depend on the device driver for the disk subsystem in question, and if/how well it implements FFB. The driver would absolutely have to respect FFB if called with a volume option because that's what must get called on a system shutdown. Would it respect FFB called with a single file or group of files as argument(s)? (a group of files might be treated in VFP as multiple single-file calls).
>>>>>
>>>>>I'd like to think if it respects the former, it *should* respect the latter. But, in a commodity market OEMs might be trying to differentiate themselves from the competition on benchmarks. It's possible they could show higher numbers if they ignored single-file FFB calls and simply left it up to a lazy-write algorithm to take care of it "whenever".
>>>>>
>>>>>To a certain extent nVidia and ATI have been engaging in dodgy optimizations to make their video cards look better in the fiercely competitive graphics world.