>Here is my related question, regarding performance and placement of exe
>
>On one of the VFP listserve (or perhaps here, sorry, cant remember),
>someone posted a performance problem to the effect that certain forms
>were so complex that if a User simple played with the mouse absent mindedly,
>moving it around the form, that network performance really degraded,
>and one could see activity or workload dramatically increase on
>some kind of server monitor. That thread went on to discuss NIC cards
>and various network tuning options, but my first thought (out of
>curiousity, because im sort of a beginner) was, WHY cant the exe,
>etc. be on the workstaton client, and just have the crucial shared
>tables on the server (as a way to maximize performance). The answer
>that came immediatly to mind (and I am wondering if my thinking is
>correct in all these matters) was that perhaps the installation has
>100 workstations, and that deploying modifications, (if it is a
>volatile, frequently modified application) would become a time-consuming
>task..... and perhaps THIS consideration was the reason why the EXE
>was placed on the server, so that changes could be deployed to
>one place, and all 100 workstations would be upgraded automatically.
>
>Question 1: Am I correct in the above assumptions.
>
>Question 2: If I AM correct, then what are the options/trade-offs
>to placing the exe on each workstation (for maximum performance)
>versus placing the exe on the server (for maximum ease of
>modification)? Are there any "tricks" or techniques, which would
>allow someone to "have there cake and eat it", so to speak.
>I think I once saw a post where, when an app was modified, some
>the new exe was placed on the server, and some flag was set in some
>table, which each client machine app tested upon every log-in.
>If the flag indicated that the EXE had been upgraded, then
>the app on the client triggered some procedure which COPIED the
>new app to the client, and forced the user to log out, and log
>back in. Is anyone aware of such a technique?
>
>Thanks,
>
>Bill Buell
Bill,
You're correct on your assumptions. But OTOH think of this :
All users run Office from an NT server < bg > If it's a fortune 500*n company that could really support it with hardware then no problem (not considering software solutions here). I certainly wouldn't let it on my system (admimistered I mean) because I'm not even rich enough to buy a SCSI HD for server (or terminal access, citrix etc). The case really differs from system to system IMHO.
I simply don't think to load network traffic for things that are possible locally. First time installation is not a problem for 100 or 1000 users I think. Nowadays anyone knows how to dblclick a "setup". A netsetup dir on server would do it. Later for updates just the exe (and really necessary files) files could be kept on server in a directory ie:updates. The main program would check and install like Bruce said easily. Even that could be left to the user and just be notified with a mail (who would deny - hey there is VFP6 now would you upgrade your VFP5 for free with a little work ?).
It's a tradeoff between installation ease and performance :) As a programmer I would choose to workload administrator :) Even visiting 100 stations for installation could be chosen by administrators volunteered (as they know their servers would have less load :)
At worst I would have a config.fpw that's directing tmpfiles to users local disk (or RAMdisk - I remember a very old accounting app I wrote that works totally in RAM till user chooses "commit" where RAM was bigger than double sided 180K diskette - who said power failure... :)
Also nowadays there are many deployment techniques are being developed especially with NT (but honestly other than knowing their existence I don't know or tested how they work). If I remember correctly there was something in Novell doing a install+update too.
What I do is to initially put it on server (depends how much time I have:). Later as time lets I move users to local. Or do it from the beginning with a netsetup.
Cetin
