From: ibisnestremovespambit@iinet.net.au   
      
   Jim Hargan wrote:   
      
   >   
   > Now for the problems. Paradox is the Tounces of the RI world. It does it --   
   > just not very well. The big problem is that the table directory paths are   
   > HARD CODED into the structure, right down to the drive letter. If you move   
   > either table, your whole application breaks. This makes Paradox RI   
   > effectively undeliverable. For a one-person standalone application it does   
   > what you want -- until you decide to buy a new computer. Then you have to   
   > EXACTLY duplicate the drive and directory structure on the new machine. And   
   > don'd even THINK about rearranging your hard drive.   
   >   
      
   Just for the record, this is not true.   
      
   All tables that have RI relationships must be in the same directory, and   
   the path is irrelevant.   
      
   However, lookup tables can potentially span directories - you could have   
   a directory for handy lookup tables, used by one or more applications,   
   with the main tables located in other directories.   
      
   Then, you can use Paradox's excellent aliases (hugely useful concept) to   
   link tables to :MyLookups:LookupOfPostCodes and so on.   
      
   Trouble is, when you relocate the tables, and redefine the aliases, you   
   discover that the aliases have been converted into hard-coded paths, and   
   nothing works anymore - a bit like M$ Work when it breaks all linkages   
   to sub-documents and other objects if you move a document.   
      
   So you can use RI and lookups very easily, but all files related like   
   this must be in the same directory.   
      
   In my case, I have lots of directories for different "sub-databases",   
   and I replicate some lookup tables that are required to be used within   
   multiple sub-databases. A minor administrative annoyance.   
      
   This is not to say that RI actually works very well. Lookups do, though,   
   to enforce allowable sets.   
      
   BTW: Metadata about table properties and linkages are held in files   
   Table_Name.VAL.   
      
   If you delete or rename .VAL files, all constraints on master-detail   
   data actions are removed, so you can do stuff like deleting master   
   records before deleting detail records, or adding detail records before   
   adding master records. Especially useful for handling groups of tables   
   that have cross-linked relationships.   
      
   You can rename them, do the business, then rename them back again,   
   without losing metadata.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)