When a partitioning storage condition is changed, table data might be deleted. Consequently, when the partitioning storage conditions of a referenced table are changed, matching between the referenced table and the referencing table cannot be guaranteed.

When WITHOUT PURGE can be used during splitting, table data will not be deleted. However, as explained in 13.13.10(2) Recovery procedure when data not satisfying the post-splitting storage condition remains, if data remains that does not match the storage conditions after the partitioning storage conditions have been changed, that data cannot be retrieved. As a result, a mismatch occurs between this data and the data in the referencing table. The following shows an example:

Explanation:

1. In this example, R03 for the referenced table contains the data 2004-12-30 and this data also exists in the referencing table. Therefore, the referential constraint is satisfied.
2. If WITHOUT PURGE is specified, the data 2004-12-30 remains in R03 that is to store the data 2001-12-31 through 2002-12-31. In this case, the referenced table cannot be searched for the data 2004-12-30, and the referential constraint is not satisfied.

If pd_check_pending=USE is specified in the system definition and the partitioning storage condition is changed for a referenced table, the referencing table is placed in check pending status regardless of whether WITHOUT PURGE is specified. If pd_check_pending=NOUSE is specified, the referencing table is placed in non-check pending status. Therefore, if you have changed the partitioning storage conditions, you must check the table's integrity and release the table from check pending status. For details, see the HiRDB Version 9 Installation and Design Guide.

The following describes the operation when partitioning storage conditions are changed for a referencing table.

• When pd_check_pending=USE is specified in the system definition
  If you have changed the partitioning storage conditions for a referencing table, an RDAREA from which table data has been deleted is placed in non-check pending status. If all RDAREAs containing the subject table are placed in non-check pending status, the table is released from check pending status (the value of the CHECK_PEND columns in the SQL_TABLES and SQL_REFERENTIAL_CONSTRAINTS tables becomes the null value).
  
• When pd_check_pending=NOUSE is specified in the system definition
  If you have changed the partitioning storage conditions for a referencing table, an RDAREA whose table data has been deleted is placed in non-check pending status.
  

The following describes the operation when partitioning storage conditions are changed for a table for which check constraint has been defined.

• When pd_check_pending=USE is specified in the system definition
  If you have changed the partitioning storage conditions for a table for which check constraint has been defined, an RDAREA from which table data has been deleted is placed in non-check pending status. If all RDAREAs containing the subject table are placed in non-check pending status, the table is released from check pending status (the value of the CHECK_PEND2 columns in the SQL_TABLES and SQL_CHECKS tables becomes the null value).
  
• When pd_check_pending=NOUSE is specified in the system definition
  If you have changed the partitioning storage conditions for a table for which check constraint has been defined, an RDAREA whose table data has been deleted is placed in non-check pending status.