>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?