>>before you run your exe file do this:
>>
>>create a file named config.fpw
>>where you put your exe program
>>this file have:
>>
>>DEFA=%:\MIDATA_DIRECTORY
>>PATH=%:\MIDATA_DIRECTORY;%\MY_HELP_FILES;etc.
>>
>>WHERE % IS THE DRIVE AN THE REST IS THE DIRECTORY WHERE ARE YOUR TABLES O DATABASES
>>
>>I NEVER HAS THIS PROBLEM BUT I THINK THIS SOLVE YOUR PROBLEM
>>
>>THE CONFIG.FPW FILE MUY BE IN YOUR EXE FILE.
>
>What I'm afraid of with doing that is that when I distribute the executable, the config.fpw in the exe will override the config.fpw in the directory with the executables.
>

I don't rely on CONFIG.FPW to set up data paths; instead, I use it to establish the runtime environment (things like TMPFILES, the status of the main VFP window before the app gains control, etc), and use a shortcut with the -c command line switch to point to a station-specific CONFIG file. I also embed a default CONFIG.FPW in the app - that way, I can establish some reasonable defaults that take effect in the event that the station-specific CONFIG isn't available.

The application code can gain control and set up data paths and the like before opening files, so a resource like an INI file or the Windows Registry can be used to point at data. You can also pass parameters on the command line to the main routine that point to a data path, or an INI file, or whatever, to establish the application context; it doesn't have to be established before the application code gains control.

Ed