>>I'm working with a scenario that's sort of similar. Now the applications can't run on their own, but a number of them read/write data from or to other tables. Fortunately, the launcher program keeps track of the installed apps and their locations. Further the tables all reside in a child directory that always has the same name. One thing that's significantly diffferent, is the fact that my applications are all on networks, rather than stand alone machines. In my case, the directory structure on the nets is standardized.
>>
>>It should be noted that the path stored in the dbc seems to be (at least in the instances I've checked) the relative path. This means that as long as the relative paths are the same, other factors (such as drive) don't matter. While I agree with the principle that "it's the user's computer and they should" have some control over things like installation directory, I wouldn't apply that to the overall directory structure that's installed. Other factors, such as planning to port the application to a network, may also override this consideration.
>>
>>George
>
>This does pose interesting issues from a programmers perspective. You've just done all your developing locally. Because you have CREATE SQL statements for views that are too complex for the view designer, it is now necessary to put a copy of the DBC on each client machine so that it may have exclusive access to create the views. The tables reside somewhere on the server. But, each clients mapping to the server could be different. Drive M for user 1 is the same drive N for user 2, and on and on.... I have installed VFP apps on a network, but I've set up each user's client machine too. But I didn't have to provide a local copy of the DBC either.
>
>I need a good way to distribute a copy of the DBC and have the DBC understand where the tables reside once copied to the local client. If the DBC on the server is different than the copy on the client, then the app should be able to copy the new DBC from the server to the local client on startup but somehow understand that the path to the tables is to the server. Any ideas?
>
>Steve

I really don't think that there's a way without modifying the PROPERTIES field of the DBC. In this scenario, if you could determine the appropriate server drive you could replace the drive specifier in the field. My tests seem to indicate that this works and doesn't cause a problem in the dbc. What I haven't tested is replacing the entire path. However, if replacing the drive works, it would seem logical that replacing the entire path would work as well. My guess here is that the binary data in the field has nothing to do with where the file is located. Admittedly, this test was run by creating another mapping to the same server. This means that the same table was being accessed. I have no idea if number records, last update or anything else would change the binary data in the field.

As you know, I don't have these sort of problems to deal with, but I'll investigate further and let you know.

George