>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