>Hello all,
>
>I have been reading as much as possible in various threads on the dos and don'ts of VFP multiuser setup.
>
>1) Don't share the .exe over the network. I understand this.
>2) Don't share the .dbc over the network. Again, I understand this, but I need some technical help here. As I understand it :
> a) the dbc has a fixed path to where each dbf is located.
> b) the dbf has a fixed path to what dbc it belongs to.
>
>So with A and B said, how do you implement a multi-user setup where each user has their own dbc and executable?

Hilmar has already given you the rundown about the .EXE.

A technical point about DBCs and paths: I haven't checked it out for newer versions but I believe the path that is stored is the minimum relative path. Some examples:

DBC location          DBF location             Path stored in DBC
C:\MyApp\Data         C:\MyApp\Data            none
C:\MyApp\DBC          C:\MyApp\DBFs            ..\DBFs
C:\MyApp\DBC          F:\SharedFolder\DBFs     F:\SharedFolder\DBFs

I seem to recall, there is a significant "gotcha" in the above - that relative paths are used
until a full path is first required, then after that a full path is always used
even if the DBFs return to a location that could be specified by a relative path. e.g.

C:\MyApp\Data         C:\MyApp\Data            C:\MyApp\Data  && rather than nothing

Something to be aware of (if it still holds true in current versions of VFP)

Also as Hilmar points out, as far as I know you have to share the .DBC on the network, precisely for the reasons a) and b) you point out. The minimum relative path can give you a little flexibility, but not much. If it is not supposed to change, you can mark the DBC and its associated files as ReadOnly files on the server which may help reduce chance of corruption and may help the NOS because it doesn't have to deal with file or record locking on them. I seem to recall some people even building their .DBC and associated files right into the .EXE if it's not supposed to change, and as long as the tables are in a constant relative path (e.g. \DATA folder below the .EXE).

I have heard that some people implement local .DBCs just to handle their views. This lets them keep the bulk of the DBC read-only, while allowing ad-hoc or temporary views to be created. It also works around a potential issue where under heavy traffic there may be lock contention in the DBC that causes the creation or update of a view to fail unexpectedly.