Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

Announcements
Talend Cloud AWS EU Scheduled Outage: Starting Tues 26 May 21:00 CEST with expected completion Wed 27 May 01:00 CEST
cancel
Showing results for 
Search instead for 
Did you mean: 
ssrlv
Contributor II
Contributor II

Failed to build update statement

[TARGET_APPLY ]E: Failed to build update statement    I am Getting this error in child task as soon as the load is completed.  I checked all column names and none are over 30 characters long.  Table name is very short.  I am getting this error in BATCH apply mode and transactional apply mode?  This is only happening for this one table. This is Oracle source and Oracle target version 19c  19.19 put level.  

Labels (1)
2 Solutions

Accepted Solutions
ssrlv
Contributor II
Contributor II
Author

There is a primary key for this table,  so only the supplemental logging PK columns is enabled.  I am reloading the table now with verbose logging on.  I will have my Linux admin run the DUMPLOG to decrypt the update statement in the log file for the task if it fails again.  

View solution in original post

ssrlv
Contributor II
Contributor II
Author

the verbose log showed that the target database was missing the PK index.  I created that index and now the table is replicating without errors.  Appears the table was dropped and the other indexes were recreated but the PK index was missing.   

View solution in original post

3 Replies
sureshkumar
Support
Support

Hello @ssrlv 

Reproduce the issue with TARGET_APPLY set to VERBOSE, why it is failing.

And also, logs are encrypted kindly decrypt the logs to check why the query its failing.

How to Decrypt Qlik Replicate Verbose Task Log Fil... - Qlik Community - 1862114

Please check whether the supplemental logging for all columns is enabled or not?

 

Regards,
Suresh

ssrlv
Contributor II
Contributor II
Author

There is a primary key for this table,  so only the supplemental logging PK columns is enabled.  I am reloading the table now with verbose logging on.  I will have my Linux admin run the DUMPLOG to decrypt the update statement in the log file for the task if it fails again.  

ssrlv
Contributor II
Contributor II
Author

the verbose log showed that the target database was missing the PK index.  I created that index and now the table is replicating without errors.  Appears the table was dropped and the other indexes were recreated but the PK index was missing.