>>Again, I would repeat do not follow this path of set relation for a simple update. That just creates a mess.
>
>Thank you for correcting me as far as which cursor should be indexed.
>But you are saying the SET RELATION TO is not necessary and then you use it in your code.
>Am I missing something?

I disagree with Cetin. I use SET RELATION TO on a regular basis.

USE child ORDER cdxTag IN 0
USE parent ORDER cdxTag IN 0
USE grandparent IN 0

SELECT child
BROWSE LAST NOWAIT

SELECT parent
SET RELATION TO iKeyId INTO child
BROWSE LAST NOWAIT

SELECT grandparent
SET RELATION TO iKeyId INTO parent
BROWSE LAST NOWAIT

Move your windows around, and you can visualize your grandparent / parent / child relationship easily.

For updates, I use them similarly where it's appropriate. It allows you to single-step through your code to examine the operation.

SELECT grandparent
SCAN FOR NOT EOF('parent')
    SCATTER NAME lo
    SELECT parent
    SCATTER NAME lo ADDITIVE
    SCAN FOR NOT EOF('child')
        * Here, you have grandparent, parent, and child aligned.
        SCATTER NAME lo ADDITIVE
        * Right now, lo contains all fields from all tables, and will iterate as it should
        * Pass lo as a memory object, copy as necessary, etc.
    ENDSCAN
ENDSCAN

Another way is to use SET SKIP TO. With that feature, you can just use SKIP in a loop, and it will auto-skip through the relationships, skipping through each child, then each parent, then each grandparent, exhausting each one before proceeding up the chain. It gives you a type of SQL-SELECT like view of the data, but with the individual tables in tact.

It's all old school, before we had fancy new functions and SQL abilities, but there are times it does make it easier to debug, easier to step through and find an issue.