I was wrong in syntax:
of course:

Open DATABASE ... Exclusive

>Thanks Bruno, worth a try.
>
>Regards.
>
>>You can try a:
>>OPEN myDBIncluded Exclusive
>>
>>If all launched EXE open, the DBC is not shared.
>>
>>HTH
>>
>>
>>>Hi,
>>>
>>>I asked a similar question to this awhile ago, but the answer(s) I received seem to contradict some tests I have made recently.
>>>
>>>Here is the scenario. An application I have been asked to maintain has its DBC "included" in the VFP EXE and the EXE is ran by all users from a network share - not from their local drive. Obviously, this is a very bad way to run the application but as there are in excess of 300+ users, the previous developers and IT department felt this overcame distribution issues. In fact, despite this "handicap" the application runs at a reasonable speed. However, if changes are made to the SQL server tables and they need to be reflected in the DBC remote view definitions, as the DBC is compiled into the EXE, then a new EXE rebuild/release has to be scheduled and this is not always convenient.
>>>
>>>Whilst the simple answer is to decouple the DBC from the EXE, the next question is potential speed degradation because of locking contention issues when users access the DBC to read the remote view definitions. What I am trying to establish is whether or not each user who loads the centrally shared VFP EXE from his/her workstation effectively has access to a "unique" copy of the DBC or, is the DBC shared amongst all the users as would be the case if it was decoupled from the EXE. It should be pointed out that the Fox runtimes are installed on each workstation - its just that the EXE is accessed from a network share.
>>>
>>>The advice I received was that the DBC would still be shared and so having the DBC in or out of the EXE would result in no performance difference, hence, it would make sense to decouple the DBC from the EXE build.
>>>
>>>However, to test, I embedded a free table in the EXE and in the application's "main" program, USEd the table EXCLUSIVEly. I reasoned that if the EXE shared "built-in" datatructures like tables and DBC's, then any subsequent running of the EXE would result in a File Access error because the table had been opened exclusively by the first accessor. When I tested the application in this circumstances, I was able to open numerous instances of the central EXE from several workstations and the EXE loaded fine, not complaining about the LOCKED table. This would lead me to believe that in this circumstance, each user who accesses the shared EXE is likely to be getting access to their own copy of the DBC contained in the shared EXE instance they accessed.
>>>
>>>Does anyone have any views (pardon the pun) on this situation? Will a single instance of the DBC be shared by all users of the EXE or will each accessor of the EXE effectively get a unique instance of the DBC ?
>>>
>>>Thanks,