home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.databases.paradox      To crash or not to crash, asks Borland      9,834 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 9,431 of 9,834   
   Jim Hargan to Robert Molyneux   
   Re: Help with Paradox 9 table schema   
   19 Aug 08 10:45:29   
   
   From: contact@harganonline.com   
      
   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   
      
   On Tue, 19 Aug 2008 07:41:25 +1000, Robert Molyneux wrote:   
      
   > 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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca