The following notes explain restrictions when linking with related products.

• When the inner replica facility is used
  
  • When you create an inner replica of an RDAREA in which a referenced or referencing table is stored, use the same generation number for all RDAREAs used to store table data having a referential relationship. If indexes are defined for the referenced or referencing table, use the same generation number for the index storage RDAREA and LOB RDAREA as is used for the RDAREAs that store the tables.
  • If the referencing table in the original RDAREA is in check pending status, do not create an entity of the replica RDAREA. Cancel the check pending status of the referencing table in the original RDAREA and then create an entity for the replica RDAREA.
  • When check pending status is set or canceled for all generations, the generations in command hold and in closed status are handled as not having an entity of the replica RDAREA. Therefore, these areas are excluded as targets for setting or canceling check pending status. If an RDAREA is excluded as a target for setting or canceling check pending status even though it has an entity, first cancel the hold status of the RDAREA and then use the integrity check utility to update the table information in the RDAREA.
  • After executing the following operations, use the integrity check utility, specifying all generations to execute data integrity checking for each table.
    PURGE TABLE statement
    Re-initialize RDAREA
    Delete replica RDAREA
    Integrate inner replica group
    
• When performing updatable online reorganization
  Data integrity is not guaranteed when updatable online reorganization and database updating are performed in batch mode. This means that, if you have set USE in the pd_check_pending operand, the referencing table might be in check pending status. In this case, use the integrity check utility to cancel check pending status. If NOUSE is specified in the pd_check_pending operand, use the integrity check utility to forcibly place the table into check pending status and then check data integrity. For details about how to check data integrity, see 12.19.5 Procedure for checking table integrity.
  
• Using HiRDB Datareplicator
  Make sure that no referential constraint has been defined for the target table.
  
• Changing partitioning storage conditions
  If you change the partition storage conditions for the referenced table or integrate or partition RDAREAs in such a manner that existing data is deleted, data integrity is not guaranteed after the partition storage conditions have been changed; in such a case, the user must check data integrity. For details about how to check data integrity, see 12.19.5 Procedure for checking table integrity.