Walter,
I'm on a Novell network. I guess the workstation client can do some fancy caching where it knows I'm the only user. I noted that VFP caches my session's index info and updates my session's cache correctly. Every update of the table has to update the cdx. Once another user changes the table, my session's cache is dirty and must be re-read. Sorta the reason a REPLACE FOR condition with its automatic FLOCK() is faster than individual REPLACEs. I didn't see that caching behavior in my WAN tests. Sometimes I tested during the work day when the tables were being changed, other times, no one was there.
I think your experience only points out that more tags, in an update situation, drags performance down even more when others are banging out changes too.

>Charlie,
>
>>Does it cache network data? It would be problematic. Since my last USE, the table structure, CDX structure, and all the data could be different.
>
>VFP can cache networkdata. Actually it's the workstation that can cache network data. On a NT network it is possible to cache read and writebuffers for shared files, given you're the only one using this table. It's a kind of exclusive mode while you opened the table fox shared access. From the top of my head, it's called Exclusive Oplocking. Another feature is that a NT server keeps the files open for a while on the serverside in case you'll open the table again shortly after you closed the table.
>
>Given these two features, it *could* make a difference. Though this theory, I never tried to examine this behaviour in detail. A simple test I did with a client: I did a replace on a 10.000 records shared table over a WAN, while no other users were using this table and another replace with other users accessing the same table.
>
>The difference in performance were really huge. In the first case it took less than 30 sec to complete. The second one took about 8 hours.
>
>I can't judge, if it would make any difference on your test, but it could be wise to take them in consideration.
>
>Walter,