Myron,
An example of what I want:
I have a parent table (Names) with 3 child tables.
After some time the client discovers that 2 names (John Smith and John Q Smith) are the same person. He wants to merge all the data for both names into 1 Name. I want to be able to change John Smith's Primary Key (13) to John Q Smith's Primary Key (199) cascading the change through all the child tables, and delete John Smith's Record.
I could write a MergeRoutine that changes all the Child.ForeignLinks from < OldValue > to < New Value >, but then when I add a 4th child table 6 months later, I have to remember to include it in the MergeRoutine.

As I said in another message, I think the approach would be something like this:
(1) Turn off the UpdateTrigger in the Parent Table.
(2) Delete the PrimaryKey that I want to lose (13 in the example) -- orphaning all the child tables with ForeignKey=13.
(3) Turn back on Update Trigger in the Parent Table.
(4) Change the Primary Key for the Valid Primary Record (change 199 to 13) -- cascading through all Child Tables (picking up all those orphaned records).

The problem with this approach is that I can't figure out how to turn off the UpdateTrigger. Although, I have recently thought of something that I haven't tried yet.
I'm going to try and change the UpdateTrigger from "__ri_update_names()" to "glUpdateTrigger and __ri_update_names()" which should prevent __ri_update_names() from executing when glUpdateTrigger=.F. So in step(1), I set the global variable glUpdateTrigger=.F. and in step(3) I set it back again.


What do you think?

>Bill,
>
>What Mark & Don suggested would be the appropriate approach. What do you mean
>when you state 'I don't know all the Child Tables'? How are you going to determine
>when you have duplicate primary accts?
>
>Once you identify the primary accts duplicates
>and which account you need to merge in the other then you update your child tables
>foreign key to the primary table. Then you can remove the primary account which
>you merged from.
>
>Are you saying that you don't know which tables are
>linked/related or have a foreigh key to the primary account table? Disabling RI for
>the primary table does not gain you anything but headaches.
>
>-myron kirby-