>I confirmed that the DBC is indeed shared across multiple instances of an EXE, even when it is compiled into the DBC. In one worker, I opened a DBC, found a record associated with a view, and put an RLOCK() on the record. Other workers then tried to open the view and received an "Attempting to Lock..." message indefinitely. I don't know how VFP shares the DBC (probably by means of temporary files), but including the DBC in the EXE alone does not make it immune to contention.
>
>However, VFP does allow you to open the database exclusively. This does not lock other workers out of the DBC and the contention issues go away as well. So, it's a two-step workaround: 1) compile the DBC into the app/exe, and 2) open the database exclusively. I am doing this when the workers startup, and so far, there are no repercussions.

This is so counter-intuitive that I wonder how did you ever get such an idea :). Glad that it worked.

OTOH, if the app used a loader, so everyone would run their own copy of the dbc inside their own copy of the exe... I wonder if the contention would ever happen. And then, would there be any speed gain if the dbc-in-exe was opened exclusively. The locking happens on the network/filesystem levels, and always takes some time, so if it can be circumvented (or at least done only once), I guess it would run faster.