Oracle Forms 4.0 Question

Hi everyone...

Please forgive the length of this post, it requires some explination.

I was hoping you would have some insight into an issue we are having with Forms 4.0.

We have designed a Form that contains three blocks. Each block is associated with a
different table, and the tables are all related to each other.

Block 1 - Table A - Parent
Block2 - Table B - Child
Block 3 - Table C - Grand-Child

Canvas1 contains Block 1 (Single Record), and Block 2 (Multi-Record).

Canvas2 contains Block 3 (Multi-Record)

There is a button on Canvas 1 that issues a "GO_BLOCK" to block 3
(Just like the forms class example of Customer Orders, and Inventory Items)

We have setup the form to allow Cascading Deletes. We want changes on the form to be immediately reflected in the database so we issue a commit after every delete.

There is actually a delete button (In a control block). If the user presses the delete button, we identify what block/item they came from,
display an alert asking them to confirm the delete request, and, if they confirm,
we issue a do_key('DELETE_RECORD'), followed by a commit.

So far so good.

The problem occurs after the delete/commit. For some reason, following the commit,
the form "gets confused".
As I mentioned above, thre is a button on canvas 1 that issues a go_block to block3.
 (just like the class example).

Obviously, the user must have selected a record from block2, before they can proceed to block3.
See Example:

(Block1)

Class ID:     ABCD
Group:          01




(Block2)


 PPL                          DESC                               Qty
F001                        xxxxxxxxx                            10
F002                        yyyyyyyy                           20
F003                       zzzzzzzzzz                           30

(Block 3 - Different Canvas/Window)

DISPLAY ITEM - Class     - ABCD
DISPLAY ITEM - Group     - 01
DISPLAY ITEM - PPL        - (which ever was selected)

IA_REC                            DESC                               Qty
1234                                   aaaaaaa                         10
2222                                   bbbbbbb                         10

The problem will work as follows. You are in block2, and delete PPL value F002...
It will be deleted as well as all it's block 3 records. The cursor will move to the prior
PPL value F001...

At this point, if you click the button to jump to block3, the form issues a WHEN-VALIDATE on
the PPL number, and he when validate fails.

#1. I cant understand why a when-validate is issued at all. No values on the form have changed. All that has happened is that a record has been deleted.

#2. I put in a Message in the When-Validate trigger to determine what the value was that is causing the failure...The message tells me that the form thinks the PPL number is now 7777 in the above example. That is, the form thinks that the PPL number is the CLASS ID !!!! This above example only takes place when a commit is issued. More specifically, it only occurs when a commit following a delete is issued. If I remove the commit, the form works perfectly.

Why would a delete/commit combination mess up oracle forms ? I cant believe that anything as fundimental as this could possibly be a bug with the product. I feel that it is most likely a design flaw of some combination of form level settings that we have made a mistake on.

Please help if you can.

Thanks

-Dan                    Received on Fri May 26 1995 - 00:00:00 CEST