When you apply or remove journaled changes, journal management
does not support referential constraints.
In the following cases, files may be in CHECK PENDING status after you
have applied or removed journaled changes:
- When you restore a file that already exists, the referential constraints
for the system copy of the file are used. Some of the journaled changes that
you apply may have been valid with the referential constraints that were associated
with the saved copy. However, they are not necessarily valid with the current
referential constraints. If you have changed the referential constraints on
the file, considering doing one of the following before applying or removing
journaled changes:
- Deleting the system copy and then restoring the file
- Recreating the changes to the referential constraints
When you apply or remove journaled changes, the system attempts to
verify the referential constraints at the end of the command, before returning
control to you. This may result in a CHECK PENDING status.
- Some referential constraints cause an action to another file. You may
define a constraint so that deleting a record in one file causes a related
record to be deleted in another file. Because referential constraints are
not enforced when you apply journaled changes, the second delete operation
does not happen automatically. However, if you are journaling both files and
applying journaled changes to both files, the system applies the journal entry
for the second file when it encounters it.
If one of the files in a referential
constraint was not journaled or is not included when you apply or remove journaled
changes, the referential constraint will probably be put in CHECK PENDING
status.
The output format for journal entries (except the *TYPE1, *TYPE2, and *TYPE3
formats) and the QjoRetrieveJournalEntries API interface include information
about whether a journal entry was created because of changes that occurred
to a record that was part of a referential constraint.