Bob,

While I certainly agree that what you describe is interesting, do you get the same lousy response if you try have user B access any other EXISTING record in the table?
If it is also a slow process, then this truly is a PROBLEM of magnitude, else it only is a serious problem *IF* the condition you are testing is expected to happen FREQUENTLY IN REGULAR USAGE of the application.

good like,
Jim N

>>How many index tags do you have for this table? If you have a lot of tags, insert and updates will be make it even slower, as well probably the complexity of the index expressions.
>>
>>John
>
>
>
>We've tried it with a single tag that has a mildly complicated index and get the same slow response. Our index expression is: bintoc(iSeqNum)+ttoc(tMyDateTime,1) Our sample data file has only 150 records and they are not unusually long records in any way.
>
>Its a fairly busy index but creating the expression shown above should, in my experience, take a LOT less than 1/10 of 1 second. Because we're looking at a 2 to 5 second delay, I feel that problem has to be something else. I really thought that user A's FLUSH command after the replace was going to solve the problem, but when it didn't, I headed to the net.
>
>When we run the same code as a single user, there is NO perceptible time delay between writing the new record and the SAME user finding it with a seek. (This may be because the new index info is available in memory, although not yet available on the disk)
>
>I'm ruling out a "slow network" problem because our debug testing has been done by running 2 copies of VFP 5.0a on the same fast machine.
>
>Thanks for responding John.
>
>Bob