IBase inconsistencies - Component corruption & Fix

[Former Member]

IBase Inconsistencies - Component corruption & Fix:

Symptom: IBase component ends up in a dump when the component is opened.

Go to TCode - IB52/IB53. Enter the component and search.

When a component is opened, it ends in a dump/Run time error 'CX_IBASE_ERROR'. (Run time error can also be found in TCode - ST22)

Scroll down to see the details of the dump

Background:

IBIN and IBST are two very important tables which govern the validity of a component (Equipment) in any IBase. Details of the component links with IBases (both old and current) are saved on these tables. The last/latest record for any component should have same validity dates on these two tables.

Go to table IBST and search for the component which ends in a dump upon opening. Check the records on IBST table.

Last row of the result is what governs the component’s validity in any IBase. This row should be taken as base for a component.

Now go to table IBIN and search for the same component. Check the records on IBIN table.

IBase component corruption issue: Reason for the dump is a mismatch in the validity dates (Valid to date) on the last records of the tables IBST and IBIN for the component. Due to this, the function module ‘IB_COM1_READ_INSTANCE_TO_RECNO’ fails to fetch the hierarchy tree structure of the IBase and raises an exception ‘CX_IBASE_ERROR’.

Fix: When the validity dates on the last records of tables IBST and IBIN are not the same. IBIN table last record’s validity should be changed to match the IBST table last record while doing this change, ensure that these records in both the tables are connecting the component to the same IBase.