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 
> upstream.
> 
> 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.
> 
> Peter