>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").
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 :)
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only