>>Ok, lets talk about the Lock contention issue with views in a DBC.
>>
>>After reading this:
>>http://fox.wikis.com/wc.dll?Wiki~CreatingDBCForViews
>>
>>People are saying that when a user access a view (e.g. Requery() ), the DBC is locked.
>>
>>If this is true, then this explains why our 40 user site is experiencing terrible performance on a gigiabit network!
>>
>>Has anyone else looked into this?
>>
>>If everyone had their own local DBC that contained view definitions, would this resolve the contention issue?
>
>My understanding of the DBC locks "issue" is that it applies only when one person is updating a view


You're mistaken. Every time a query executes, the record is locked, long enough to extract the query from the DBC, then unlocked. It seems the lock is done to prevent someone attempting to update the view defintion while someone is trying to run it.


>, and it locks only the DBC record related to that view. So ask yourself:
>
>- how often does anyone using the app modify a view?
>- how long is the lock held on that view record? If modified via code, probably only a small fraction of a second. Even if modified via the View Designer, it depends on whether the Designer locks the record pessimistically or optimistically. In the former case the lock could last as long as the user has the Designer open, in the latter it's likely to also be only a small fraction of a second while a "Save" is done. I don't know if View Designer locks are optimistic or pessimistic.
>
>In either case, unless your app makes use of the View Designer (or users are opening it in VFP interactively on a production DBC) then it's likely view records are being locked for only a small fraction of a second. The lock contention would occur if another user happened to try to requery that view at the precise instant another user is updating it.
>
>In short, it's an error that should not occur very often, but in a heavily used production system should be trapped for completeness.

The more queries are run OR the more users, the more likely there will be a contention.

>
>There likely are MANY other reasons for poor performance on a gigabit LAN (search the threads here for [slow performance network] or similar for discussions). I wouldn't spend a lot of time trying to nail down this rare condition without testing for more likely problems first, such as
>
>- bad hardware - cabling, switchgear, NICs
>- antivirus (test with it disabled on both server and workstations to see if that makes a difference)
>- improperly configured DNS on modern W2K/W2K3 Server/XP workstation LANs
>
>etc. etc.