Personally I don't see any great advantage with what you've stated. Using relative paths I have a \DATA\MYAPPSDATA\ directory locally for testing (this way I can keep working even if the server goes down). I also create a \DATA\MYAPPSDATA\ on whatever server and drive the app is to run from. If I need to change servers or drives I just create the same relative path when moving the data. Both approaches work fine and I disagree with you that either one works better.

Anyway, my main point was to not hard code drive letters in code.

>Just my two cents here, but I disagree with this idea. What happens when the data is on the \\DataServer machine and now that machine just died. You are also hard-coding paths...
>
>If you go with Edward Pickman's idea, you would just have to stick the data into a directory on a machine that is alive and change a record in the configuration file, and presto, back to work.
>
>I use this method and it is great for testing. I use a copy of the live data (in a test directory) and just change the configuration file and now I can go crazy testing things with no danger of corrupting the live data.
>
>Also, we have several sets of data (different blocks of business) on the same network. This method allows for this type of flexibility...
>
>Joe
>
>>>>>Hello. Having trouble hard-coding drive assignments in visual foxpro for users on a network in Win95. To some users a shared network drive is one letter and to another user it's another. Is there a good way to reference "use t:Thisfile" as opposed to "use S:thisfile"?
>>>>>Thanks
>>>>
>>>>Each user may have own local configuration table which besides other things will store path to network data folder.
>>>
>>>so ahead of time, manual case by case basis must be evaluated for each user?
>>
>>I agree with David's suggestion. IMHO, I would suggest avoiding hard coding drive letters and only use relative paths.