>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 :)
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement