Unexpected Multiple Updates in Oracle Target When Using Qlik Replicate with AS400 Source

[EE_]

Dear Support Team,

We are experiencing an unusual behavior in our Qlik Replicate environment. The source endpoint is AS400 and the target endpoint is Oracle.

When a single update is performed on the AS400 source, we observe that Qlik Replicate executes 54 update operations on the Oracle target for that same record. This seems excessive and unexpected, as there is only one update on the source side.

Currently, the replication task has transformation settings applied, but there are no filters configured.

Could you please help us understand why this is happening and how to prevent the unnecessary multiple updates on the target?

Thank you for your assistance.

[john_wang]

Hello @EE_ ,

It appears that a single update operation on the AS400 source may have affected 54 rows, which is why Qlik Replicate replicated 54 update events to the target.

If you’d like to investigate further, please enable SOURCE_CAPTURE/TARGET_APPLY logging at the Verbose level. Then, reproduce the behavior and review the task log files to help identify the root cause.

Hope this helps.

John.

[EE_]

Hi @john_wang ,

Thank you for your response.

We would like to clarify that the update on the AS400 source was performed on only one row, not 54 rows. However, we still observed that Qlik Replicate generated 54 update operations on the Oracle target for that single updated row.

We can confirm from the source system logs and application behavior that only one record was updated on AS400.

Thank you for your assistance.

[john_wang · Accepted solution]

Hello @EE_ ,

There are several ways you can confirm how many rows were affected by a single UPDATESQL statement:

1. Enable SOURCE_CAPTURE / TARGET_APPLY logging to Verbose, and review the Replicate task log file to see the number of affected rows.

2. On the AS/400 (IBM i) side, you can run the DSPJRN (Display Journal) command to examine how many journal entries were recorded for the update. This can help determine the number of rows that were affected at the source.

3. Most SQL execution tools will return the number of affected rows after a statement executes. You can get the affected numbers In Access Client Solutions (ACS), dbeaver, Python with ibm_db or ODBC etc.

Hope this helps.

John.