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
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/Custom...).
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?
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.
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?
