Problem in implementing Master-Detail-Detail design in Forms 6i

Question

Hi, all technocrats!!
Here i've problem in Master-Detail-Detail sort of design in
Forms 6i..
This thing i've implemented earlier in one form...and that is
fine...and i could not track the root when i've got a problem in
a new form...which of the same manner...
The problem is that...
When i enter data into the 1st detail block and navigate to the
2nd detail which is a detail block to the 1st detail...and enter
data, there is no problem, but when i navigate back to the 1st
detail block and that to a new record in the 1st detail...form
is showing indefinite behaviour( Hanging )...
But when i navigate back to the same record in the 1st detail
from the 2nd detail...there were no problems and it is working
fine...
And whenever i shift to a new record in the first detail it is
asking to save that record...to solve this problem., i've used
POST in the new block instance of the 1st detail...and i'm
comfortably managing it...if i dont use this POST method...it is
clearing the details in the 1st detail itself when i traverse
back to it from 2nd detail after inserting records...
But this hanging problem is really driving me to Hang myself...
Plz do suggest me to get rid of this problem...

Answer 1

Developing proper transactional behavior with Oracle Forms
in Grandparent-Parent-Child case is a problem.
We must use some 'container' for 'non-visible' Child records
(Child records with Parent different from current record in
Parent block).
I try to solve this problem in 2 different ways:
1. Using POST built-in. In this case 'container' is Child
database table. But, problem can be 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) temporary database table, PL/SQL table of records
(defined in Forms package or database package), Forms record
group. This variant has not problem with record locks/database
triggers, but is much more complex for programming than 1.
variant.
In my development, when I haven't problem with record locks or
database triggers, then I use POST. In other cases, I use 2.
variant, with PL/SQL table of records (defined in Forms package)
as 'temporary container'.
Further, when we use POST, we can do this in more ways.
One method is to use POST in Forms level WHEN-NEW-RECORD-
INSTANCE trigger.
Different method is to change code in CLEAR_ALL_MASTER_DETAILS.
Instead of:
CLEAR_BLOCK (ASK_COMMIT);
we can write:
IF mastblk = "name_of_master_block" THEN
CLEAR_BLOCK (ASK_COMMIT);
ELSE
POST;
END IF;
Which method you use?
Regards
Zlatko Sirotic