Mark,
While it is a lot more work you can make this relatively dynamic. The only thing being that the remote data must always exist on a share of the same name. If this is true then you can search the connected network to find all the active workstations, check their shared directories and find the share you have your database in. For example, \\PC1\DATADIR is the current location of data. Next week you move it to PC2. Make sure the share is named DATADIR so the share would be \\PC2\DATADIR.

I wrote a VB COM server to do this but you can do the whole thing in VFP with Ed Rauh's CLSHEAP and NETRESOURCE classes in the Files section. You use these to retrieve a list of all the PC currently connected to your network and their available shares. If the name is right, check for the existence of your data and you have it. This way, you never have to visit each PC when a change is made.

The one drawback is initial startup application startup. Scanning the network (especially a WAN) could take an extremely long time. To alleviate this, you could store the last location of the database locally (registry or INI) and check this initially. Only if it is not there do you search the network again.

Just some ideas.

>Thanks Sergey
>
>This is one of the approaches I have considered.
>
>However using the Windows registery means that each workstation has to be revisited in the event of a change of location for our data.
>
>And storing it in an INI file with the application means we have not achieved 100% seperation.
>
>I guess I will end up having to use an INI file since there seems to be absolutely no other way of doing it.
>
>
>
>>>Our department has finally decided on an approach of keeping all data completely separate from the applications.
>>>
>>>This will enforce the discipline on us required for any possible upsizing that may be required later.
>>>
>>>This is fine...except if I cannot store any data of any kind with the application how do I tell my application where the database container for the application is located.
>>>
>>>At the bare minimum I must store at least one path.
>>>
>>>Or I must hardcode at least one path into my application. This of course goes against the grain of what I have practised for years.
>>>
>>>I can think of a few options none of them very tidy.
>>>
>>>How do other people deal with this situation?
>>

---

>>You don't have to harcode path into your application but you have to store it outside of your application.
>>You can use Windows Registry, INI file or table to store it.