Hi!

I agree with Paul Maskens - looks like in VFP8 FLUSH also flushes internal OS buffers. This, indeed, going to be very slow. I can bet after seeing such slowness, VFP guys would like to make an option to switch off this feature in FLUSH.

As a solution to this and similar things, I use FLUSH/100 (or more) records, that speeds up processing a lot.

>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