What you are asking for is not the normal fashion that Forms works.
When you navigate back to block B from block C then select a different row in block B, then it will try and change the contents of the coordinated block C, thus prompting you to save the contents before they are lost.
One way you could achieve this maybe is to store all of the results as you are entering them in background arrays. But this is made more complex if you want to go back and change things before saving. Then when you commit, you save the contents of the arrays.
Developing proper transactional behavior with Oracle Forms in Grandparent-Parent-Child case is a problem.
ADF doesn’t have this problem.
In Forms, we must use some "container" for the "non-visible" Child records
(Child records with a Parent different from current record in Parent block).
I am trying to solve this problem in two different ways:
1. Using the POST built-in.
In this case the "container" is a Child database table.
But, there could be a problem because POST built-in actually executes DML statements
(this locks records and fires database triggers - so a deadlock can occur) before COMMIT_FORM.
2. Using a "temporary container".
"Temporary container" can be (for example) a temporary database table, a PL/SQL table of records (defined in Forms package or database package), or a Forms record group.
This version has no problems with record locks / database triggers, but is much more complex for programming than the first one.
During development, when I don’t have a problem with record locks or database triggers, I use POST.
In other cases, I use the second version, with PL/SQL table of records (defined in Forms package) as a "temporary container".
Moreover, when we do use POST, we can do it in a number of ways.
One method is to use POST in Forms level WHEN-NEW-RECORD-INSTANCE trigger.
Another method is to change code in CLEAR_ALL_MASTER_DETAILS.
we can write:
IF mastblk = "name_of_master_block" THEN
It’s not easy job, and there are a lot of little details to solve.
I would also go with the POST-solution and use the ON-CLEAR-DETAILS to do the POST. As POST sets the form-status to QUERY, you should "tick" an item in your master-blcok after the POST, so that the status is CHANGED again (could be something like :MASTERBLOCK.ID:=:MASTERBLOCK.ID;
Thanks Tony ,Zlatko and Andreas for replying.
Zlatko your method solved my problem.