>>The July issue of FoxPro Advisor had an article on this subject, I think.
>>At least it dealt with off line views. You can get a synopsis of it at the
>>Advisor site.
>>
>>You're absolutely right about stand alone machines/applications and the
>>user having the ability to define the location of files. However, in this
>>case, you have circumstances (future plans) to override this. Perhaps the
>>gendbc.prg might be of help. Don't forget that the DBC is nothing more than
>>another table with a different extension.
>>
>>George
>
>Yes, it's just a .dbf, but having some weird data in the memos, with
>lots of strings embedded between binary codes. Took me whole day just to
>temporarily remove primary keys so my indexing routine could create
>indexes from scratch and restore the keys afterwards.
>
>I'll give you a worse scenario, and I can't say if I'm anxious to see it
>happen. In FPD2.6 we are dealing with a suite of apps which plug into
>each other - there are some tables shared. Each of the apps instals into
>a directory below the \app directory (disk doesn't matter as long it's
>the same disk), and has the path names of shared tables (better to say
>"tables borrowed from neighbors") in a set of variables. Now, as each of
>the apps must be capable of running as standalone or as a plugin, at
>installation time we set those variables according to the availability
>of other apps, to its own directory or someone else's (the table names,
>structures are the same). We do it with zip code table, customer table
>and some others. We configure it in different ways, and it always works,
>no problem.
>
>Now how could this work in VFP/DBC model? Should I have the paths to
>each of the other apps' DBCs? What if I have the same table in local and
>remote DBC, should I have to put the DbcName!TableAlias syntax
>everywhere? Patch each and every DE to revert to "variable containing
>the full path to table" model (if this is possible at all)?
>
>Anyone?

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