>>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 ?