>>> 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.
>

Yes, the FLUSH was before the closing, I just mentioned the basic steps without all the details. There was a subroutine with locking and unlocking in place. The solution was not to rely on incremented key only, but to make the ID unique within the system, using extra prefixes.