From: contact@harganonline.com   
      
   Gotta tell you, your information on setting the work directory to the   
   /child/ really blows my mind. And it makes perfect sense in the Paradoxian   
   Universe.   
      
   My problem is: your approach is the result of a well-thought-out design. My   
   approach is the result of random hacking. Example: so I have a travel diary   
   app, just for me, very usable. Hey! I could link it to my main photography   
   database and suck in all the photos I took that day! Then I could link it   
   to the invoice database and see how much money I made! (If any :-( .) Very   
   cool! So I now have yet another subdirectory, aliased as :TRAVEL:.   
      
   I have 13 such sub-databases. And that's how it works in Happy Hacker Land!   
      
   I am irritated by your discussion on how it could all work anyway, mainly   
   because it would make Windows a really neat environment if it ran that way,   
   but it doesn't. Nevertheless, I am left with the nagging feeling that it   
   *could* work, and maybe it's only a rainly Sunday project away.   
      
   Well, nothing wrong with dreaming. In ten days I go to Prince Edward   
   Island, one of the most beautiful spots on the planet, for four weeks. Yay!   
      
   --   
   Jim Hargan   
      
      
   On Wed, 20 Aug 2008 07:18:33 +1000, Robert Molyneux wrote:   
      
   > Jim Hargan wrote:   
   >> Much here that is new to me! Like you, I use a lot of sub-directories for   
   >> self-contained child databases -- so everything I use is always aliased,   
   >> and therefore ends up hard coded.   
   >>   
   >> Jim Hargan   
   > Hi Jim,   
   >   
   > If you change the working directory to the child database, when you do   
   > the linkage of tables for lookups you do not need to use aliases. From   
   > then on, Paradox simply assumes that the main table and the lookup table   
   >   are in the same directory, and does not store the pathway.   
   >   
   > Then you can reset the working directory, and still reference the tables   
   > using aliases, with all relationships working correctly.   
   >   
   > If you do use aliases, you can move the database from one system to   
   > another provided that you can map the location to the same letter on the   
   > new system as on the old. For example, I used to have all my tables   
   > nicely set out in directories, heavily cross-referenced with aliases,   
   > and all saved in Q:\Database_Directory. So long as I could snaffle the   
   > Q:\ mapping there was no problem. But of course, generally this is not   
   > acceptable.   
   >   
   > Some years ago I suggested in this forum that (a) aliases were a really   
   > great concept, and (b) the way they were turned into hard-coded paths   
   > was a really great boo-boo - and got all sorts of strange responses...   
   >   
   > In the Amiga OS (now THERE was a great OS) you could define symbolic   
   > paths that all software including SuperBase (quite a good RDBMS) could   
   > use - so you could have My_Main_Database and My_Handy_Lookup_Tables and   
   > so on configurable. The nearest that M$ OS has are things like   
   > MyDocuments and shares - but you really need to be able to define shares   
   > within shares.   
   >   
   > It would be handy to have a "directory" / "module" concept in CS   
   > databases - that is, be able to put tables into logical groupings within   
   > one CS database - maybe already there?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)