Nah. I thought I was being more economical by having my key structures like this:
PARENT1 CHILD1 CHILD2 CHILD3 CHILD4
------- ------ ------ ------ ------
CHILD1 <->CHILD1...........................
..........CHILD2<->CHILD2..................
...................CHILD3<->CHILD3.........
............................CHILD4<->CHILD4

(I hope the fonts don't screw up the diagram too much)

I think it is clear that I need to SELECT TO CURSOR two generations at a time, REPLACE FOR in both generations, then APPEND back - then skip down one level. Next, I have to figure out if I can do one pass per generation, or several.

>>>Well, I seem to have painted myself into a corner with this one. I have coded an application with 1 to Many parent/child relations going six deep. Each relationship is using internally generated key fields.
>>>
>>>Now, my client (internal) is asking for the capability to copy a relation tree from the top down to a new record - with it's own copy of all the children, grandkids, great grandkids, etc.
>>>
>Do your key structures look something like..
>PARENT1
>PARENT1.CHILD1
>PARENT1.CHILD1.CHILD2
>PARENT1.CHILD1.CHILD2.CHILD3
>PARENT1.CHILD1.CHILD2.CHILD3.CHILD4
> ...etc?
>
>copy all for left(MyKey,7)="PARENT1"
>..
>set exact off
>seek [PARENT1] && Will locate all children for this parent in all tables
>..
>set exact off
>do while seek([PARENT1.CHILD1])
>replace CHILD1 with newCHILD1
>enddo
>..
>Whty do you need to re-configure the keys?
>
>Some times you can put all the children in with the parent in one table!
>ALLCHILDREN.dbf
>fields
>PARENT CHILD1 CHILD2 CHILD3
>000001 000000 000000 000000 && Parent record all children are zero
>000001 000001 000000 000000 && First Child 1 record, child 2 and 3 zero'
>000001 000001 000001 000000 && Firsr Child 2 record
>000001 000002 000000 000000 && Parent one second child 1,
> ... and so on