A script-enabled browser is required for this page to function properly.

About Complex Relations and Cascading Deletes

When you set the Delete Record Behavior property of a relation to Cascading, be aware that deletes are enforced only for the immediate detail block in the relation. For example, consider the complex master-detail relation involving relations between blocks A and B (A_B), and B and C (B_C) where B is both the detail block in the A_B relation and the master block in the B_C relation.

When the Delete Record Behavior property is Cascading for the relation A_B, the detail records in Block B are automatically deleted if the master record in Block A is deleted. Detail records in Block C are not automatically deleted when a master record in Block A is deleted. If, however, the Delete Record Behavior property of relation B_C is Cascading, then detail records in Block C are deleted when Block A is deleted. Detail records in Block C are affected by the deletion of Block A, because when the Delete Record Behavior property is Cascading for the A_B relation, the deletion of a master record in Block A causes the deletion of the detail records in Block B. The detail records in Block B also serve as master records in the B_C relation. Since the Delete Record Behavior property is Cascading for the B_C relation, the deletion of a master record in Block B causes the deletion of detail records in Block C.

Master-with-dependent-details

A master-with-dependent-details relation includes a master block and n levels of detail blocks, such that the first detail block is itself a master for its own detail block.

To create a master-with-dependent-details relation, define the individual relations A_B and B_C separately (in any order).

When you create this type of relation, consider the effect of the Delete Record Behavior and Coordination properties on the detail blocks. For example, if one relation in a chain of related blocks is set to deferred coordination, all subsequent blocks will also be deferred. Thus, when relation A_B is deferred and relation B_C is immediate, Oracle Forms does not coordinate Block C with Block B until Block B is coordinated with Block A.

Master-with-independent-details

A master-with-independent-details relation involves two or more detail blocks, both sharing the same master block. This structure is useful when you want to display more than one set of detail records for a single master record. A coordination-causing event in the master block results in both detail blocks being populated with the appropriate detail records.

In the sample application, the master block REGION could be displayed along with the detail blocks WAREHOUSE and CUSTOMER. The end user could then see all of the warehouses and customers within the currently selected region.

To create this type of relation, define the individual relations A_B and A_C separatel (in any order).

Detail-with-two-masters

A detail-with-two-masters relation involves a single detail block that has two master blocks. Oracle Forms displays the appropriate detail records for whichever master block is the current block in the form. For example, in the sample application referred to earlier, the ord block could be a detail block having two master blocks, CUSTOMER and EMP. End users could then see all of the orders for a particular customer, or for a particular sales representative (employee).

Usually, when you create a detail-with-two-masters relation, you will be joining on different foreign-key items in the detail block. In such cases, the Copy Value from Item property is set for each foreign-key item in the detail block to point to the primary-key item in the appropriate master block. To create this type of relation, you need only define the two relations; Oracle Forms will automatically support coordination.

In other cases, however, you might want to create a master-with-two-details with each relation joining on the same foreign-key item in the detail block. However, because the Copy Value from Item property can only point to one master block item, you will need to write additional code to coordinate querying and updating for the second relation if you are joining on the same item in the detail block.

Depending on the desired functionality, this might include writing a Pre-Query trigger for the detail block to ensure that the correct primary-key item value is copied to the foreign-key item in the detail block. For example,

COPY(NAME_IN(:system.master_block||'.primary_key_item'),
'detail_block.item');

You might also want to create a When-New-Block-Instance trigger that checks the coordination status of the detail block whenever the end user navigates to a different master block, and, if necessary, populates the detail block.