Look at launcher apps. The user has an icon that starts a small .exe. This launcher exe compares your main application exe against a copy on the server. If the one on the server is more recent than the one on the pc, the one on the pc is replaced. The one on the pc is always executed.

With Visual MaxFrame Professional it is possible to build one exe for the majority of the framework stuff, deploy that on the pcs, and have a second exe (your app) use the framework contents in the first exe. This can result in a 3Mb exe being broken into a 2Mb framework exe with a 1Mb application exe.

Honestly I'm amazed how frequently your situation is the norm. A 3Mb exe x 100 users is 300Mb of wasted network traffic. If they launch more than once a day, it just gets worse.;)

I understand it simplifies upgrading, but everything is a trade off...you pay a price. I believe there is also regular access of the FoxPro support files as the application runs. Caching mitigates this to some degree. But no network traffic is always better than some traffic.

You'd have to make an install kit for the launcher and your application. Then you don't have to know the files go in System32 ;). Send these to the users. Put the install kits on the server and send a shortcut to the users so they can install. The users install both one time, (new machines too). You would update the server copy as necessary. You can also exclude screens, reports and middle tier objects from the main exe and have the launcher copy them to the local pc as they change. This can make a huge impact on how quickly you can distribute fixes.

Local views are still going to involve passing around some amount of index data so the PCs can determine which records to extract. VFP buffers some data when tables are opened. Both of these are overhead not found in CS apps.

>I will test, thanks. I'm guessing that these files need to go into System32 directory? DB