Jim,

I may be mistaken, but the impression I have is that one cannot rely on FLUSH to truly force out changes to disk, because this does not address the issue of additional buffering at the operating system level. Maybe there's also something beyond that as well, but whatever the reason, the test would be to flush and pull the plug. Less drastic variations are also of interest, e.g. what happens if you kill the task without crashing the machine. Does FLUSH assure that after such failures you can return to a clean DBF/FPT/CDX, including the latest update? This is the question.

Mike

PS Thanks for the feedback about Montage. Let's talk about that under its own thread, rather than intermingle it under this entirely different subject. I do appreciate your comments, as even the little you've said is instructive. (It shows me the importance of making things immediately clearer, e.g. with some additional screen shots and descriptions of typical usage scenarios.)

>Hi Mike,
>
>Well I wouldn't know how to check that it now works or that it didn't work before or whatever.
>
>Got any ideas?
>
>I would think that there is a GOOD chance that the beta has debug code in it, but it STILL seems inordinately long to me. But I don't know how to determine that either, save by asking others to try and report their observations.
>
>cheers
>
>PS I might have downloaded "MONTAGE" if I could see what it is really "aimed" at and it's basic operation. I'm not sure what problem it is solving, nor its 'scope' of operation.
>
>
>
>>Hi Jim,
>>
>>Maybe the issue is that it now actually works. I'm just guessing, but this is something worthy of knowing. Perhaps your thorough testing skills might be applied to that question. Guessing again, and wishing, it could be that the beta is inordinately slow compared to the optimized release version.
>>
>>Mike
>>
>>>Using VFP8 public beta.
>>>
>>>I have a program that I've run at least 25 times over the last month in VFP7 SP1. It creates 3 tables (with associated CDX & FPT of course) of 500,000 records each and regularly runs in around 30 minutes.
>>>
>>>I've shied away from running it under VFP8 because of my understanding that betas may contain lots of debugging code and other stuff that slows things down, and my interest lies strictly in timing things here and in later runs.
>>>
>>>But this morning I decided that I now had my data of interest for VFP7, so I'd give it a go in VFP8.
>>>I brought up the beta VFP8 and recompiled the program in question, then ran it.
>>>After 1 hour of running I stopped it (Esc/suspend) and found that it had written only about 15,000 records in each file, and this was with SET EXCLUSIVE ON.
>>>I changed it to SET EXCLUSIVE OFF and reran. This time I Esc'ed after a half hour and found that 1,300 records had been written.
>>>In both cases above I had a FLUSH command. And I noticed that the HD light was hard ON throughout the runs.
>>>I revised the program again, this time to remove the FLUSH. I ESC'ed after about a minute and 13,500 records had been written, so I resumed it. This time the HD light flashed on/off, as it had done on all VFP7 runs. It finished within the timeframe of other runs (modestly faster actually).
>>>
>>>So it looks like FLUSH runs ultra-long in the VFP8 public beta. I certainly could see trace/debugging code being used for it, but that still seems inordinately "expensive".
>>>
>>>Can someone confirm similar in their beta? Can someone offer sensible reasoning for my observations?
>>>
>>>Thanks
>>>Jim Nelson