>> For example, ones I I had to deal with FP DOS app which was generating the duplicate keys on NT network, where the typical scheme for key generation was used (lock the record, increment the next available key value, close the table, FLUSH) <<

The sequence should have been: ..., FLUSH, Close (or FLUSH, UNLOCK in other situations).

"Closing" released the Lock before changes were written to disk.

In my experience, "closing" tables does NOT automatically result in an immediate FLUSH (contrary to popular opinion).

FLUSH is one of the few FP/VFP command (besides .Draw()) that functions synchronously; CLOSE/USE (and the implied FLUSH) do not.

My conclusions were based on observing disk activity ... which, BTW, also confirms how "smart" BROWSE/Grids can be; they will often only "fetch" enough to fill a screen, even with GO BOTTOM (sort of like "Client/Server").