Hi Gerry,

>>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".
>
>In my experience, FLUSH has always been "slow" (and it has always "worked").

Well the same code with the same FLUSH in VFP7SP1 (and even a single run in VFP6SP5 a few weeks back) only slowed the overall process by less that a couple of minutes. Here it would have been the better part of a day for it to finish.

>
>FLUSH is a synchronous command; I use it after every write in an OLTP context, but would never consider using it after every write in a "batch" scenario, because, as you found out, the physical writing slows the app down too much.
>
>Most of my "batch" processes will do a file lock, do all the updating, FLUSH, and then unlock. Only in some cases will I do more than one flush in a batch job, and that would be at some convenient "sync" point (eg. after processing a master and all its associated transactions/children ... but only if it was a "significant" unit of work).
>
>As for the perceived slowdown of VFP 8 vs VFP 7, perhaps it is due to fragmentation :)

Well it was to create fragmented data to test exactly that < s >
FYI, once I got the data created the fragmentation (and not) tests showed a very marginally faster running of Select-SQLs under VFP8 (despite reports here that VIEWs and some SQLs seemed very much slower). These were relatively simple, and my attribution is to the half-sized CDXs produced by VFP8 c.f. VFP7SP1.

cheers