thanks rick - this is along the same lines as suggestions I received from Naomi and Craig. That would have been good to know when I started this whole thing as it is client bought licence for multiple copies of VFP9 and right to alter code so we are pretty well locked into the current arrangement. Each station therefore has VFP9 installed.
I will send the FXP's now and stop the bulk deletions - that should speed things up a bit.
many thnks
k

>>when updating program files on client computers i have been sending a zip of
>>the new .prg (about 30 at a time usually) then once downloaded at the other end,
>>client vfp shuts down - then at startup i have vfp remove all .fxp files.
>>
>>the problem here is that the program is sluggish for first few run throughs as the
>>fxp files are re-created.
>>
>>Is there a better way of handling the fxp files? for example can i send the new .prg 's together with
>>the related fxp from my computer and eliminate the removal of all fxp files at the other end.
>>
>>any suggestions appreciated.
>>
>>tnx k
>
>We've always used a .EXE for distribution, and actually a two-part .EXE system. We have LAUNCHER.EXE, which can be named anything, but reads a .DBF file of the various versions installed. Whenever more than one version is available it will ask the user which one they want to run, or there are switches to allow it to automatically run the latest version, and so on. In that way we simply distribute versions like this:
>
>

* Version 1.00 through 1.02
>myapp_100.exe
>myapp_101.exe
>myapp_102.exe
>
>* Version 2.00 and so on...
>myapp_200.exe

>
>The launcher.exe never changes, but reads in a table which has information about the user settings. This usually has a user table as well with login abilities, so a superuser can log in and make changes to the settings, remove bad versions, run fixes, etc. Once the launcher has been setup, its purpose is to read the table and see what executable is supposed to be run, and then run it with a "DO (table.cDosName)" command, which runs the executable as per its information stored in the table. There is error checking and what not to make sure the file exists, but in general that's what happens.
>
>Distributing the .PRG files is a good thing in terms of sharing your source code. You could also consider sending them the .FXP files as well, and then not deleting them at startup.