>>>Hi,
>>>
>>>I would like to know if the following approach is possible and how. I am showing the pseudo code in exact order it has to go:
>>>
>>>1. The program creates a Cursor Adapter and of course it has a cursor. Lets name is CA_Cursor.
>>>2. The code populates/fills this cursor CA_Cursor with some records (getting them from the DB).
>>>3. The code updates this cursor CA_Cursor but does not update the DB (that is, Tableupdate() is not fired).
>>>4. The records from the CA_Cursor are copied/appended to another cursor (of exactly the same structure). Say, named CA_Second.
>>>5. Steps 2 - 4 repeated several times. Therefore, the cursor CA_Second now has records from every iteration of steps 2-4.
>>>6. Detach cursor CA_Cursor from the CA object and Attach cursor CA_Second to the CA object.
>>>7. Execute TableUpdate() to update the DB
>>
>>Why not have two cursor adapters, the first one sending no updates?
>
>Thank you. But this won't work for my case.

Your approach might work, but would depend toooooo much on the for us black box of CA internals.
If you are working with automatic filters
If I read you intentions correctly, I would try a different strategy:
create a CA with a flag and some code in the update hook methods to allow you to fire a "local tableupdate".
the local tableupdate does NOT update the remote table but moves all UD statements either into a program and/or a table with values, so the second table is much smaller. You will have to rethink validation of those buffered updates affecting new changes as well.
Possible, but I would REALLY argue for a different base idea to implement.


//upd: thinking a bit more, you did not even define if the second cursor acts like a FIFO stack or if you intend to Upsert records in second table (dunno if a record can be selected and updated twice in your biz case)