>>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.
>
>There is no problem with sharing the EXE. My users do it all the time. Some people here, however, will recommend to use a loader program that copies the latest version of the EXE to the local drive. I won't deny that this should be faster, but it also works fine if the EXE is run directly from the network.
>
>I do have a loader program that checks for the latest version, but then runs it directly from the network. This loader program makes it possible:
>
>a. To upgrade the EXE without having to throw out all the users.
>
>b. For users to go back to a previous version, as a temporal solution in case there is some problem with the latest version.
>
>>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.
>
>Neither do I see any problem with sharing the DBC. The whole point of a networked system is to have shared data.



>
>>So with A and B said, how do you implement a multi-user setup where each user has their own dbc and executable?
>
>No idea, but I don't deem this necessary.

No offense intended, but may I ask why fine, and good enough are so often the answer? Why not go for the best performance, the easiest upgrade as opposed to trying to kick everyone off so you can put up a new exe? You're using a loader, so why say it's not necessary?

The exe run from the server causes network traffic not just at the start, but continuously while the app runs, everytime the user starts a new form, or prg or whatever.

The loader is architecturally better, no? Why isn't it being recommended as the standard approach?

I agree there should be shared data. The DBC is largely metadata, and sharing it is unnecessary. :)