This content has been marked as final. Show 5 replies
Most of the time integration id's are the primary keys in source system.1 person found this helpful
They will be used to differetiate unique record in the table.
Whenever you face such issues it means that you might have duplicate entries otherwise you need to relook
into your configuration
Identify duplicates using below sql and try to delete them
from W_EAM_WORKORDER_F group by INTEGRATION_ID,DATASOURCE_NUM_ID,ETL_PROC_WID having count(*)>1
Delete from W_EAM_WORKORDER_F where integration_id =?,datasource_num_id=?,ETL_Proc_wid=?
But It is not advised to delete these entries which may lead to data mis match.
So identfy duplicates and try to fix them.
mark correct or helpful if it helps,
Do we have a way to ignore the tasks or ignore the errors in DAC and continue with the rest of the steps ?
Also i found out this ...
The required staging table columns, DATASOURCE_NUM_ID and INTEGRATION_ID are loaded into the staging table.
INTEGRATION_ID stores the primary key or the unique identifier of a record in the source table and DATASOURCE_NUM_ID stores the datasource from which the data is extracted. These required columns are used by SIL mapping to generate the surrogate key for OBAW.
Nope..You cant ignore..Each one of the tasks have priorities assigned to them and run based on the parent tasks run's.
One of my colleague told me to go to Design view and then inactivate that index through indices tab.
I did that and the load completed successfully.
Now just wanted to understand, what would be the repurcussions of it?
Thats not a good practice..You are not suppose to inactivate index.
There might be implications on reports giving you wrong results(Because of duplicate entries) and running slow..
Try to identify the duplicate entries and then fix instead of bypassing the issue.