>>Hi,
>>
>>I have a 3 MEG VFP5.0 executable residing on an NT server.
>>
>>I have 35 clients using Win95 to connect to NT to access this application.
>>
>>When each terminal initially loads the EXE into memory there will be some network traffic - fair enough.
>>
>>When each client is using the system, will any more traffic be created from accessing the EXE or does the Win95 client keep the entire thing in memory.
>>
>>Ideally the only traffic we require is the raw data required to use the EXE, not the EXE itself.
>>
>>Any ideas?
The entire 3MB executable is not kept in memory; the .EXE file is referenced pretty frequently, in fact.
Running a local copy of the executable, rather than the copy on the network, will remove the additional LAN traffic from VFP referencing the .EXE. A shortcut can be created that runs a local .EXE starting in a network directory; this approach is probably best, or at least easiest, to manage.
The issue of keeping the .EXE up-to-date does surface when each station has its own local copy - you need to do more than simply copy the new executable in place where everyone can run it. One approach that I use is to have a loader; a small .EXE that checks a central network copy of the executable (or a .APP) against the copy on the local station. if the copy on the local station is less recent than the master copy, the master is copied over to the local machine. Once the examination and possible update have completed, the current local copy is fired via 'DO
'.
This changes some things in VFP startup management. Since the actual .EXE or .APP isn't fired directly, it becomes necessary to move the CONFIG.FPW out of the compiled application itself, either to the loader, or preferably, to each local machine as an editable text file. The local CONFIG.FPW can be enabled by adding the -c command line switch to the shortcut firing the loader. The advantage of a local CONFIG.FPW, allowing you to tune the locations of temporary files and the like on a machine-by-machine basis, far outweigh the cost in creating it during installation and referencing it appropriately in shortcuts.
>>
>>Kind regards,
>>
>>Kev
>>
>>BrainBashers: www.internet-uk.com/puzzles
>
>One common work-around for this problem is to install a 'loader' program on each workstation.
>
>When this runs, if there is no local copy of the executable, or the date of the local executable is earlier than the copy of the executable stored on the server, the loader program will copy the latest executable from the server to the workstation, The loader then runs the local copy of the executable.
