When migrating data using the EIM, the process can fail due to several reasons. In certain cases, it is found that the EIM process was successful for migration into some of the Base tables, but failed for some other base tables. In other cases, records get imported into the base tables, but some of the columns fail migration. This section discusses the various causes of EIM failure, how they can be tracked and finally resolved.
After EIM process is complete, the following SQL query has to be run, to check for possible errors:
SELECT if_row_batch_num, if_row_stat, if_row_stat_num, count(*)
FROM <<EIM Table Name>>
GROUP BY if_row_batch_num, if_row_stat, if_row_stat_num;
Common Errors and Resolution
The following chart lists the possible values of IF_ROW_STAT, what they indicate and some possible resolutions.
IF_ROW_STAT | Indicates | Resolution |
|---|---|---|
IN_PROGRESS
| Integration Manager sets IF_ROW_STAT to this initial value for all rows in the batch. If rows still have this status value after Integration Manager exits, a failure occurred that aborted processing for this table.
| One possible reason may be that an extension column in the Base table that the EIM table maps to does not exist.
Another reason may be that there is insufficient space in the Siebel Server for the generation of LOG files. |
SQL_ERROR
| A SQL error occurred during an attempt to import this row. This error occurs for rows processed when transaction logging is TRUE.
| In this case, the SQL statement that failed execution is logged in the EIM log file. This statement can be analyzed to deduce the specific error. |
IMPORT_REJECTED
| A user-specified filter query failed for this row.
| The query specified using the FILTER QUERY parameter needs to be analyzed and corrected. The query expression should be a self-contained WHERE clause expression (without the WHERE keyword) and should use only unqualified column names from the interface table or literal values (such as NAME IS NOT NULL). |
FOREIGN_KEY
| A required foreign key column in the target table could not be resolved.
| One reason could be that all the columns in the EIM table that map to the foreign key in the base table have not been populated. Another reason could be that the EIM table columns mapping to the foreign key column, resolve into a ROW_ID that is non-existent in the Foreign Key table. |
PICKLIST_VALUES
| A required picklist value in the target table could not be resolved. This error occurs for NULL or invalid bounded picklist values.
| The error could be resolved by ensuring that a picklist exists for the column that is LOV bounded. The value being imported for this column corresponds to one of the values in the picklist.
|
REQUIRED_COLS
| One or more required columns for the target table were NULL.
| Before running the EIM, it should be ensured that the required columns in the base table(s)are being populated. Even if these columns are not specified in the EIM table, they could be defaulted to specific values using the DEFAULT or FIXED COLUMN parameters in the IFB file. | |
DUP_RECORD_EXISTS
| The row exactly matches rows that already exist in the destination tables. This error can also occur when the same record (same user key) exists with the same EIM batch number with a lower ROW_ID. In this case, MIN (ROW_ID) is the record processed, and the other records with the same user key are marked as DUP_RECORD_EXISTS.
| It should be ensured that in the EIM table, records with the same batch number have distinct unique key combinations. | |
PARTIALLY_IMPORTED
| The row did not fail for the target table (although it may have been a duplicate), but did fail during processing of a secondary base table. This status is set after the import has completed.
| In case, a parent-child relationship exists between the target table and the secondary base table, the user keys mapping to the Foreign Key column in the Child table referencing the Parent table must be populated in the EIM table in exactly the same way in which the user key columns resolving to ROW_ID of the parent table are populated. | |
DUP_RECORD_IN_EIM_TBL | Indicates that there are 2 or more interface records having the same user key values. | To avoid this situation, analyze the input records before beginning the EIM task. If you find duplicate records, you can either combine them into one record, or specify a different batch number for the duplicate record. 4 | |
NON_UNIQE_UKEYS | This error occurs if there is more than one USERKEY, say <<Basetable name_U1>>, <<Basetable name_U2>>, etc. defined on a base table. The particular EIM table being used to populate the base table uses the second USERKEY but the user has populated EIM columns corresponding to the columns of the first USERKEY | It is necessary to identify the particular USERKEY that the EIM table uses and populate columns mapping to that USERKEY uniquely.5 | |
AMBIGUOUS | This error is usually encountered when there are some columns in the Base table, other than the unique key columns, which also need to be uniquely populated for each record. This is because of unique index database constraint defined on these columns. This error is also encountered when attempting to run DELETE or MERGE processes on records in the base table with same unique keys but different conflict_ids. | The workaround is to identify all the column combinations in the base table, which participate in the different unique index constraints defined on it, and populate each combination uniquely. 6 | |