|Subject:||Re: Referential Integrity
|Date:||Fri, 30 Nov 2018 16:40:19 -0800
Thanks for the taking the time to write Tom
Your suggestion to build my own ri is what I feared because I will have
to make certain to remember to add every new table to a table acting as
a registry and then update manually.
The transfer of ownership is the part I am currently working on. You are
correct that the invoice history links has to remain with the original
owner for accounting and for maintaining customer history but the there
is also the need for the vehicle servicing records to follow the vehicle.
On 11/30/2018 04:07 PM, Tom Krieg wrote:
> First thing - when a vehicle is sold you do not want to change the owner
> id of the invoice table to the new owner. That will screw up your
> accounting records no end. I had a very comprehensive automotive system
> back in the 90's, written in Paradox, and had hundreds of RI links.
> Eventually I found out early that
> 1. Paradox RI doesn't work. A simple 1:M relationship works. Go down
> more than 1 level or try and reference another record in the same table
> (i.e. part number supersessions) and it falls apart.
> 2. If you're going to use Paradox tables, use tcursors, explicit locking
> and build your own RI. It's not difficult, especially if you put your
> tcursor handling in libraries. Do all your tcursor updates, then refresh
> your form.
> Peter wrote on 1/12/2018 8:22 AM:
>> I learned sometime back that the problem with using ri is that when a
>> child table is locked, Pdox places a lock on all the parent tables
>> The advantage of it is that when the parent table is updated then the
>> child table's foreign keys are also updated at teh same time. This has
>> a huge benefit in the following dm
>> Owner -->> Vehicle -->> Invoice Hist
>> Oid Vid Iid
>> Oid (fk) Vid (fk)
>> Oid (fk)
>> In the above example if a vehicle is sold to another customer then the
>> O(wner)id is changed in the Vehicle table but if connected using ri
>> then it (Oid) is also updated automatically in the invoice history table.
>> I have hundreds of tables that have foreign keys of the above tables.
>> If I do not use ri then the only thing I can see is maintaining a list
>> of all child tables and run a syncronizing routine on each in the
>> correct sequence.
>> Is there any other way of approaching this besides using ri?
>> Thanks for any thoughts.