Interesting area to look at. I found that operating system level caching was a big factor, not just VFP caching. Even after a VFP FLUSH there was still cached data at various levels in the OS, at redirector on the workstation, at the server redirector, at the server hard disk queues.
I could see my application running fast, then slowing down to a crawl after processing 250000 records or so. I progressively disabled caching and managed to make it run slow always, but not quite as the slowest with caching on. So it made it more predictable but slower. FLUSH periodically made little overall difference, the time taken by the local FLUSH was gained in filling up the caches, then lost by the write-behind process.

I could not get a FLUSH to actually write the data, right now. Not without turning off caching and write-behind on the server and turning off caching on the workstation (who needs performance anyway?). That left the OS level HD queues which I couldn't get rid of. I'm ignoring the cache in the HD itself of course, that's hardware :)

The only time I could get FLUSH working fast and reliably was with FPDOS 1.02 LAN and later FPD versions on a Novell network. But that was of course a far less advanced system that Windows XP/2000 today.


What MS might have done in VFP8 is to make the FLUSH work not just in VFP's cache but also to flush the workstation's operating system caches. That would conceivably make a FLUSH take longer.