Processing Databases with Logical Relationships

Generally, there is no difference between the processing of physical databases and logical databases: all call functions are available for both. Some considerations do apply, however, when accessing a logical child of a concatenated segment.

Accessing a Logical Child in a Physical Database

When accessing a logical child in a physical DBD, you should remember the layout of the logical child. A logical child always consists of the logical parent concatenated key (that is, all the consecutive keys from the root segment down to and including the logical parent) plus the logical child itself: the intersection data (see Figure 15-5 on page 251). Understanding the layout of the logical child is especially important when inserting a logical child. You receive an IX status code when you try to insert a logical child and its logical parent does not exist (except at initial load time), which typically happens when you forget the logical parent's concatenated key (LPCK) in front of the logical child (LCHILD).

Note:

In general, do not use physical databases to process logical relationships.

Accessing Segments in a Logical Database

The following considerations apply for each call function when accessing segments in logical DBDs.

Retrieve Calls with a Logical Database

Retrieve calls work as described in "Retrieving Segments" on page 248 with the same status codes. However, the concatenated segment always consists of the logical child segment plus, optionally (dependent on the logical DBD), the destination parent segment.

Replace Calls with a Logical Database

In general, replace calls work the same as described in "Updating Segments" on page 252. When replacing a concatenated segment, you can replace both the logical child segment and the destination parent. However, you cannot change a sequence field. The following sequence fields can occur in a concatenated segment:

• Destination parent concatenated key.

• Real logical child sequence field: the sequence of the physical twin chain as defined for the real logical child. This field can partially overlap the logical parent concatenated key.

• Virtual logical child sequence field: that is, the sequence of the logical twin chain as defined for the virtual logical child. This field can partially overlap the physical parent concatenated key.

• The key of the destination parent itself.

If any of the sequence fields is changed during a replace operation, a DA status code is returned, and no data is changed in the database.

Delete Calls with a Logical Database

In general, delete calls work the same as described in "Deleting Segments" on page 253. However, if you delete a concatenated segment (either of the two versions), only the logical child and its physical dependents (the dependents of the real logical child) are deleted. The destination parent can be deleted only through its physical path: the delete is not propagated upwards across a logical relation. You can delete only those dependents of concatenated segments that are real dependents of the logical child. For example:

• If, in the logical DBD of Figure 7-6 on page 76, a PART segment is deleted, the associated STOCK and DETAIL segments are also deleted. However, the associated CUSTOMER ORDER and SHIPMENT segments remain.

• If, in the logical DBD of Figure 7-6 on page 76, a CUSTOMER ORDER segment is deleted, the associated DETAIL and SHIPMENT segments are also deleted. However, the associated PART and STOCK segments remain.

The logical child and its physical dependents are always deleted whenever one of its parents is deleted.

Insert Calls with a Logical Database

When you insert a concatenated segment, the destination parent must already exist in the database. You can provide the destination parent together with the logical child in the IOAREA, but that destination is not used. In addition to the normal status codes, an IX status code is returned when the destination parent does not exist.