Figures 7-4 and 7-5 show the table and index status after re-initialization for an RDAREA containing a table and index. Figure 7-6 shows the conditions of a re-initialized table, columns of abstract data type of the LOB attribute, plug-in columns, and a plug-in index that are in the RDAREA to be re-initialized.

If the KFPX14255-W or KFPX24242-W message is issued during RDAREA re-initialization and the cause of the error is an invalid RDAREA status, see the HiRDB Version 8 System Operation Guide for details about increasing the size of the RDAREA and changing its attributes.

Figure 7-4 Table and index status after reinitialization (1/2)

Note

Initialized status means that there is a definition but there is no data; an index on this status is usable. Incomplete status means that the table and index no longer conform; an index on this status mode is not usable.

Figure 7-5 Table and index status after reinitialization (2/2)

Note

Initialized status means that there is a definition but there is no data; an index on this status is usable. Incomplete status means that the table and index no longer conform; an index on this status is not usable.

Figure 7-6 Conditions of a reinitialized table, columns of abstract data type of the LOB attribute, plug-in-supplied columns of abstract data type, and a plug-in index

Note

Initialized state refers to a condition in which an index is defined without data, so that the index can be used. Access-disabled state refers to a condition in which data has been deleted from the index, so that the index consists solely of a definition. In this condition, the index cannot be used. Incomplete state refers to a condition in which the table and the index are mismatched, so that the index cannot be used.

If referential constraints have been defined for a table stored in the RDAREA that is to be re-initialized, the check pending status is changed. The check pending status is managed by the data dictionary tables (CHECK_PEND columns in the SQL_TABLES and SQL_REFERENTIAL_CONSTRAINTS tables) and by the table information in the RDAREA. For details about the check pending status, see the manual HiRDB Version 8 Installation and Design Guide.

The following examples show the check pending status changes when USE is specified in the pd_check_pending operand in the system definition and RDAREAs are re-initialized.

1. When there is an RDAREA that stores only indexes
   

   

   When T2 (referencing table) references T1 (referenced table) and RDAREA3 stores only the index for the primary key of T1, the check pending status is changed during re-initialization as follows:
   

   RDAREA to be re-initialized	Check pending status of T2 (referencing table)
   	Data dictionary table	Table information in RDAREA2
   RDAREA1	P	P
   RDAREA2	N	N
   RDAREA3	--	--

   Legend:

   P: Check pending status is set.

   N: Check pending status is released.

   --: Check pending status remains unchanged.

2. For a row-partitioned table
   

   

   When T2 (referencing table) and T3 (referencing table) both reference T1 (referenced table), and when T1 and T3 are both row-partitioned tables, the check pending status is changed during re-initialization as follows:
   

   RDAREA to be re-initialized	Check pending status of T2 (referencing table)		Check pending status of T3 (referencing table)
   	Data dictionary table	Table information in RDAREA2	Data dictionary table	Table information in RDAREA2	Table information in RDAREA3
   RDAREA1	P	P	P	P	P
   RDAREA2	N	N	P	N	P
   RDAREA3	--	--	--	--	N

   Legend:

   P: Check pending status is set.

   N: Check pending status is released.

   --: Check pending status remains unchanged.