>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
Have you tried playing with the SET REFRESH command?. If you have not then the other users will be refreshed every 5 seconds with new information.
You can try SET REFRESH TO 1. (just remember, the lower the number, the more network traffic)