Scan the Order Header table for changed records using GETNEXTMODIFIED function. Use GETFLDSTATE function to see if the record was deleted, inserted, etc. Then based on that result, see which cursor needs to be processed first with respect to just that header record. You will be using the TABLEUPDATE function on ONE record at a time instead of all records at once.

>How do you all handle the updating of cursor adapters in a parent child situation where there are RI triggers on the server?
>
>Let's say I have a CA for the OrderHeader and another one for the OrderDetail..
>And there are RI constraints on the server between the OrderHeader and the OrderDetail..
>
>If I was dealing just with inserts, I would want to tableupdate the orderheader first, so that the foreign keys would exist when I updated the orderdetail.
>
>If I was dealing just with deletes, I would want to delete the OrderDetail first so that RI would not fail when I deleted the OrderHeader.
>
>What do I do when the orderheader cursor and the orderdetail cursor contains both inserts and deletes?
>
>I could certainly weaken or get rid of the RI constraints.. but that seems like an undesirable solution.
>
>If I have cascading deletes from the orderheader to the orderdetail, and tableupdate the orderheader first, the transaction would still fail when it then tries to tableupdate the orderdetail which contains deletes for the records which now have already been deleted..
>
>I suppose I could just not delete children at the front end when I'm deleting the whole order and let the cascading deletes handle it all..
>
>Does someone have a cleaner solution? (other than not using cursor adapters at all??)