>Ed,
>
>Yes, I did install the runtime on each pc locally, its MY APP I installed on the server once,
>
>Should I have a problem installing my app on a second pc. From memory, it got confused because it was already installed ?
>

It sounds like you need to create several installs:

(1) Server install - loads the app and base data to the server beneath a commonly accessible and known share, which will be the primary application directory, puts a copy of the workstation install into a folder beneath the primary application directory, creates a shortcut that will start the application in the proper network directory and places it in the base application directory. If the application needs to run on the server itself, install the VFP runtime too.

(2) Workstation install - install the runtime and any ActiveX controls needed by the application on each local workstation. After the ActiveX and runtimes install, run a post-setup executable that looks to the parent directory and copies the shortcut for the app to the desktop and/or Start Menu. I'd also tend to create a custom CONFIG.FPW for each station that pointed to a local drive location (not the root!!!!) to use for temporary files - if no CONFIG.FPW is found in the Starts In directory, there's no embedded CONFIG.FPW, your shortcut doesn't specify an exact file in the shortcut using the -c command line parameter, and you do not have a FOXPROWCFG environment variable that points at a CONFIG.FPW for the station, your executable will first look to the folder containing the VFP runtime for a CONFIG.FPW, and then searches the DOS path for a CONFIG.FPW, in order of specification.

I don't have this particular problem - I use a launcher app (not written in VFP; it could be, but VB or VC++ have significant advantages from my POV in this capacity - they're smaller and have better/easier hooks to Win32 API functions that I use in the launcher. I've done the same thing using WSH and VBScript, but it isn't as fast. I require WSH 2.0, Shell 4.71 or later and IE 4 or later to make the WSH COM objects, Shell.Application and InternetExplorer.Application available to my apps) that manages the configuration and starts the executable in the proper location with an appropriate CONFIG file specified by the -c command line parameter.

I put the executable on the local system to make it start up a bit faster, reduce the load on the network slightly, and it allows me to swap in a new executable and other components on the server and the launcher checks that the local components are up to date before the application is started. I can also use the WSH as a lightweight scripting tool if I need more extensive work done before the app launches. I have access to whatever resources you might want to use to do things - COM, a full blown programming platform, etc. are there for the asking. All the launcher does is checks to make sure everything is up to date, fire pending scripts, kick the tires, light the fires and launch the app.

Since the NetSetup for the workstation runs from a subfolder, the post-setup executable can identify the location for the base application directory by getting FULLPATH('.\..') if you fire the post-setup executable from the workstation install directory. If you installed the WSH or included George Tasker's LNKFILES.DLL, you could use it to build the shortcuts dynamically; this lets you use different shares that point to the same directory from different places.

I'd either require identical drive mappings for all stations, or use UNCs to reference the target executable and Starts In directories in the shortcut.

There's more to creating a decent app installation and management facility than you might expect. Solid installation and management planning pays off later.