Handling primary key changes with DELETE + INSERT

raffaelec — Mon, 31 Aug 2026 12:00:39 GMT

Hello,

I’ve configured a replication task that reads from a Log Stream and replicates data to a Snowflake target with Apply Changes Processing enabled, meaning that changes are applied directly to the target tables in Snowflake. The source of the Log Stream is an Oracle database.

Moreover, I’ve implemented a soft-delete logic in this task by adding a technical field defined as follows:

CASE ifnull(operation_indicator('DELETE','UPDATE','INSERT'),'null') WHEN 'null' THEN 'INSERT' ELSE operation_indicator('DELETE','UPDATE','INSERT') END

This is the soft-delete implementation described here: https://community.qlik.com/t5/Qlik-Replicate/Operation-Indicator-as-New-column/td-p/2061166.

Occasionally, operations are performed on the source that modify primary key fields. This is not a problem for Qlik Replicate, which correctly updates the corresponding record in the target table. However, this change is processed as an UPDATE. This can be a problem for consumers of the target table. If they read the table using an incremental approach, they have no indication that the record with the previous primary key has been modified or no longer exists. Therefore, if a downstream table is updated incrementally using a MERGE, this change will not be captured correctly.

I tried to investigate if it’s possible to transform the UPDATE into a DELETE of the record with the previous key, followed by an INSERT of the record with the new key. I found that this is possible for Change Tables populated using Store Changes Processing: “DELETE and INSERT when updating a primary key column: For tasks configured with streaming target endpoints (for example, Kafka), the DELETE+INSERT statements will be executed on the actual target. For all other target endpoints, they will be executed in the associated Change Tables. This option requires full supplemental logging to be turned on in the source database” (https://help.qlik.com/en-US/replicate/May2026/Content/Global_Common/Content/SharedEMReplicate/Customize%20Tasks/tasks_applychangtunestab.htm#ar_tasks_custom_1624443382_1694425).

However, I need to apply this logic directly to the target tables, rather than to Change Tables, using the soft-delete approach. This would allow consumers of the target table to identify that the record with the previous primary key no longer exists, even if they read the table incrementally (for example, by reading only the changes from the last day).

Is there a way to transform a primary key UPDATE into a DELETE + INSERT for regular target tables (not Change Tables)? Is there a way to achieve the same result using the soft-delete logic described above?

Thank you in advance for your support.

Best regards

Re: Handling primary key changes with DELETE + INSERT

Chanty4u — Mon, 31 Aug 2026 13:31:50 GMT

No. Qlik Replicate cannot transform a primary-key UPDATE into a DELETE + INSERT directly on regular target tables when using Apply Changes Processing.

But you can try below

use Store Changes Processing/Change Tables if downstream consumers require explicit DELETE + INSERT events, or implement the PK-change handling downstream in Snowflake using the appropriate change metadata.

Re: Handling primary key changes with DELETE + INSERT

Jon_Donker — Thu, 03 Sep 2026 22:30:34 GMT

Not knowing a lot about working with snowflake; but could you replicate to a "landing" table and then write triggers off the landing table to handle the DELETE + INSERT into your main table?

topic Handling primary key changes with DELETE + INSERT in Qlik Replicate

Handling primary key changes with DELETE + INSERT

Re: Handling primary key changes with DELETE + INSERT

Re: Handling primary key changes with DELETE + INSERT