A utility statement may leave a user space in a state in which its further processing may be restricted (see chapter “Utility concept” ).
Details of the utility statements that can be executed in connection with a user space in a specific state and the state the user space assumes as a result of the statement are provided in the “SQL Reference Manual Part 2: Utilities”.
Spaces in a “copy pending” state require COPY.
Spaces in a “load running” state require RECOVER and then possibly RECOVER INDEX.
Spaces in a “recover pending” state require RECOVER.
Spaces in a “check pending” state require CHECK CONSTRAINTS. If CHECK CONSTRAINTS reports integrity violations, the violations must be cleared.
Using SQL statements to work with tables in a “check pending” state
Tables in a user space that is in a “check pending” state ) can only be worked on by their owners, using SQL statements that manipulate data. Using this approach, all records that violate an integrity constraint can be adapted or deleted. A prerequisite here is that these SQL statements are issued with the pragma CHECK OFF. Syntactically, the pragma CHECK OFF is an ordinary SQL comment. However, it allows SQL statements to be executed on tables for which integrity constraints have been violated. A pragma begins within an SQL statement with the string “--%” and is terminated with an end-of-line character. The CHECK OFF pragma is described in detail in the “SQL Reference Manual Part 2: Utilities”.
A further means of correcting violations of integrity constraints is for the owners of the tables in question to delete the violated integrity constraints with the SQL statement ALTER TABLE ... DROP CONSTRAINT.
Once all violations of integrity constraints have been deleted, the database administrator must once again execute the utility statement CHECK CONSTRAINTS in order to make the affected user spaces or tables available to the authorized groups of persons again.