I've done something like this:
The first time a user runs the application, it determines that a table called "mytable" doesnt exist on their local machine (in the same spot they installed the app.) Now since this table doesnt exist, I take them to a screen asking them for the location of the datafiles, or if it's the initial install on a network, where they want to put the datafiles. Then I update the "mytable" table with this info, from then on that is what I use to determine my pathing. I've even done this wih a simple text file instead of a table a few times too. Like I said I build all this into the application itself...so even if they do something stupid like delete the .dbf or .txt file, then all that happens is the 'pick file locations' screen runs again.
FYI - once I made my 'pick file locations' gizmo look like typical windows wizard screens over 90% of my users were able to figure it out on their own.

>I could use some help with path management in distributed applications. My applications usually launch via a startup.prg which contains a couple of statements like this:
>
>set default to \foxpro\rtp_new
>set path to .\data,.\programs,.\reports,.\forms,.\classes,.\menus,..\classes
>
>This works fine on the development machine. However, when the application is compiled, distributed, and installed by various users, it may not reside in the "\foxpro\rtp_new" directory and the set path to statement will generate an error if the user has installed it somewhere else.
>
>I have tried various uses of sys(2003) and sys(2004) but I can't seem to find a technique that works well on both the development machine and the final user's machine unless I absolutely control where the user installs the application. Many users don't like to be told where the application must reside and so I need to find a way to give the greater flexibility. Can someone advise on the proper technique for this?
>
>Thanks