I appreciate the reply. It would be nice to have a concise answer on the who/what/where/when/why of DBC locking with views. Granted, it makes sense to me that the DBC would be locked if you are editing a view. But in my case, the application makes no attempt at creating or editing views in its DBC.

Can anyone else sound-off on this issue?

The following two quotes from different sites say that querying a view does infact lock the DBC:

1)
"One advantage that a CursorAdapter has over the Local View is the lack of a DBC. Since the view is a DBC object, it can only be contained within the DBC. Views can be a problem in applications where lots of users attempt concurrent access to the same view ? VFP acquires a short lock on the view record in the DBC, and sometimes this presents unexpected errors. Without the need for a DBC, CursorAdapters will never suffer from this problem."
http://www.code-magazine.com/article.aspx?quickid=0301062&page=4
------
2)
When opening views, Visual FoxPro locks the DBC because view definitions span many records. As the number of users grow, and as the number of views opened and closed by the application grows, sooner or later you'll be fighting for locks on the DBC. Therefore consider the following schema: Develop using a single DBC (which is convenient) but upon distribution create a companion DBC containing only the view information, and make your view opening code or view classes go to the companion DBC for view definitions. Users can then have local copies of the View DBC, and there is no lock contention. More details on Creating DBC for Views.
http://fox.wikis.com/wc.dll?Wiki~BigSystemPerformanceAndVisualFoxPro~VFP
-----