>>>>>You all are right, but, in a network environment is a lot easy
>>>>>to maintain an application if it is broken in pieces. I do that,
>>>>>let's say that you need to make a change to a function or report,
>>>>>right at the moment while users are working , you have to make
>>>>>the change, recompile and stop users from working to replace
>>>>>the "exe" file, in the other hand, if your function or report
>>>>>is a stand alone file, you just need to replace that file,
>>>>>and you have a good chance to do it without stoping the users
>>>>>from working.
>>>>
>
>
>>This is a silly argument - you have to force all users to log out to perform I
>I didn't say that you have to logout the users.
>
>the update in any case, and the launcher automates the process of updating - instead of forcing the user to log out and then run an external update routine, then return to his app, all you have to do is update the server copy of the executable, and then have the user exit from his app and restart it, which then triggers the update process automatically.
>
>>
>>IOW, the launcher-automated update is a win-win situation - as stations run the launcher, they automatically update the system. Any other way requires manual intervention at each station, rather than a simple phone call or message telling the users to exit from the program and restart the app when the update is ready to run.
>
>Try that with 400 hundred users, I have done it, and allways there
>is somebody that doesn't do it.

(1) You can force users out from the server, at least with NT and NetWare. See your network administrator to find out how. There are serious ramifications to forcing a disconnect from a network in an unexpected fashion with an application actively accessing network-shared resources.

(2) You have a bigger problem with manual intervention; reaching 400 user stations and running something by hand is more difficult (at least IMO) than automating the process. if it's a major issue, you can control the whole process with NT's SMS if you're running in an NT domain. OTOH, the manual update process brings a measure of job security I guess.

(3) If your users are really a problem, you can add code to your app to automate a shutdown using an ActiveX component interfacing to something like MSMQ. This could be used to force a VFP shutdown remotely, but you'd have to write the code to do it, with the some of the same consequences as unexpectedly terminating a network connection.

I've dealt with hundreds of users running an app before, and from experience, automated updating using either a launcher strategy or SMS packages is a huge improvement over running from machine to machine with a CD or floppies to update the system. Trust me, it's even worse with a WAN and multiple sites.