Hi Hilmar,
I think network folks should do a better job separating data from apps from user files. I would propose often used database files get a complete backup each night-not incremental. That way you can restore the Database as a unit. That means the most logical folder structure is one that makes it easy to backup some things incrementally and others completely.
Vol_1/Data -> Complete each night
Vol_1/Apps -> Perhap once a week or month.
Vol_1/UserStuff -> Whatever has changed.

My opinion is that the data doesn't belong under the app, but in under a separate folder organized for databases. If you only have one DBF style app on the network, I guess I doesn't matter. I'm used to having several dbf type apps running at once.

>Well, what I do is have all paths relative to the executable:
>
>Executable in \\MyServer\MyApp
>
>Data in \\MyServer\MyApp\Data
>
>Help in \\MyServer\MyApp\Help
>
>Path = "Data;Help"
>
>HTH, Hilmar.
>
>>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