Check pending status in referential constraints

Check pending is the condition of a constraint relationship when potential mismatches exist between parent and foreign keys. When the system determines that referential integrity might have been violated, the constraint relationship is marked as check pending.

For example:

• A restore operation where only data in the dependent file is restored and this data is no longer synchronized (a foreign key does not have a parent) with the parent file on the system.

• A system failure allowed a parent key value to be deleted when a matching foreign key exists. This can only occur when the dependent and parent files are not journaled.

• A foreign key value does not have a corresponding parent key value. This can happen when you add a referential constraint to existing files that have never before been part of a constraint relationship.

Check pending status is either *NO or *YES.

Check pending applies only to the constraints in the established state. A referential constraint that is established and enabled can have a check pending status of *YES or *NO.

To get a constraint relationship out of check pending, disable the relationship, correct the key (foreign, parent, or both) data, and enable the constraint again. The database then verifies the constraint relationship again.

When a relationship is in check pending, the parent and dependent files are in a situation that restricts their use. The parent file I/O restrictions are different from the dependent file restrictions. Check pending restrictions do not apply to the constraints that are in the established and disabled state (which are always in check pending status).

• Dependent file restrictions in check pending
  These restrictions apply to a dependent file that has an established and enabled referential constraint in check pending.

• Parent file restrictions in check pending
  These restrictions apply to a parent file that has an established and enabled referential constraint in check pending.

Parent topic: