The impact of integrity constraints on the forward recovery process depends on whether all dependencies of all tables in the database are contained within that database. During the recovery process, if all dependencies of all tables are contained within the database in question, and you have not requested individual table recovery or selected a subselect of the recovery (such as, by job name), the system assumes that integrity is not violated.
In all other cases, tables defined with integrity constraints which are processed by the recovery function are marked CHECK-PENDING, indicating that referential integrity must be checked (see CONFIRM (Verify Constraint Integrity). Applications attempting to access such tables may receive a return code, as indicated in the following chart:
|
For forward recovery: |
Then: |
|---|---|
|
If a table references another table (is a child) |
DELETES are allowed, but ADDS and UPDATES generate a CHECK-PENDING return code. |
|
If a table is referenced by another table (is a parent) |
ADDS are allowed, but DELETES and UPDATES generate a CHECK-PENDING return code. |
Note: You must CONFIRM tables in the following order, from referenced-to-referencing, or parent-to-child, that is to say, the referenced table cannot be in check pending status. For example, if there is a foreign key from a REMARKS table to a LINE_ITEM table on PO_Nbr and Line_Item_Nbr, and the LINE_ITEM table has a foreign key that references the PO table on PO_Nbr, the PO table must be loaded first, then the LINE_ITEM table can be confirmed, then the REMARKS table can be confirmed. Therefore, the confirm order would be: from PO table to LINE_ITEM table to REMARKS table.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|