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