>>>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.
>>
>>Hi Luis - I have to respectfully disagree here, at least in part. I agree with keeping reports out of the build, but having only one exe I think is the best way to go. There's no need to stop users from working to replace the exe. Many of us use a "launcher" exe instead. Here's a my scenario:
>>
>>1) On server, there exists a "launcher" exe which is run from desktop.
>>2) On server, there exists current build of app exe
>>3) On user machine, there exists app exe
>>
>>Launcher checks version/timestamp of user exe vs. server exe, and either runs user exe or writes new version to user machine and then runs it. Either the launcher or server exe can be replaced in about two seconds, and so far as I know no user has ever bumped into that short window...
>
>
>Hi Bruce, that is a good idea, I liked it. I only see a
>weakness in it. What about if you need to change a critical
>procedure or function, the users that are already login won't
>notice the change, and you know users, they login in their
>computers and don't logout for weeks if they don't need to.
>You can force them to logout, I know that, but
>like in my case with more than 400 hundred users distributed
>in 3 buildings is very tedious. What do you think ?

This is a silly argument - you have to force all users to log out to perform 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.