>>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. I didn't point out that we build the apps the same, no matter if they'll run in a network or not. It's only the disk letter that changes. Consequently, all data paths are relative, like OtherAppPath_gc=FullPath("..\OtherAppDir\") So, initially, it's relative and at launchtime converted to absolute path (it's my secret religion that using full path is a bit quicker :). The trick I'm looking for is using a variable to store the (full or relative) path to a table or DBC, so it can be put into the DE instead of using hardcoded paths. >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. I've even been looking at hex dumps of memo fields in a .dbc, and you're right - the paths are relative, both in the DBC (path to the table) and in the table's header (path to the DBC). >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 I agree with the principle (though I don't use it - my apps always install below \app :) - but then we are installing them and not making floppies, using the time for configurations and user education), and it seems to be quite commonly accepted in Windows (and DOS, for the matter), with the app's liberty of creating subdirectories below the one user chose taken for granted. Installing it on a local or networked directory didn't change much, but, OTOH, I've never done a full app in VFP, and never tried install. When I come to the installation issues, I'll surely shout here :)