>>As you are probably aware, VFP locks records in the DBC when opening a view. If multiple users access the same DBC, there can be contention and delays while VFP waits for a lock. For this reason, it is common to put a separate copy of the view DBC on each workstation. The same problem can occur with ParallelFox, but at a local level. Multiple workers (instances of the same EXE) can hit the view/DBC at the same time and cause contention issues. To work around this, I have compiled the DBC into the EXE, thinking that each worker would essentially get its own copy of the DBC. However, "Attempting to lock..." still blinks while multiple workers access the same view. Anyone know what happens behind the scenes when you compile the DBC into an EXE? Is it copying it to a temp location and sharing it across all EXEs?
>>
>
>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.

I think just opening the database exclusively will work without the need to compile the DBC into the app.
Only glitch of course is that you can then run only once instance of the app at a time per machine.