topic Archive Process ... Two sources One Target in Qlik Replicate

Archive Process ... Two sources One Target

PGN — Tue, 20 Jan 2026 14:24:37 GMT

Question about a database process that archives from one table to another. We have a source that will archive from one table to another in another database. What would happen if we used the same source table in two different databases, but use the same target? The goal is to have the target not impacted by the archive process.

So, if the source table removed the record from table a and add it to table b, it would delete it from table c on the target. But if table b is also set to replicate to table c, would it add it back in?

Re: Archive Process ... Two sources One Target

DesmondWOO — Wed, 21 Jan 2026 02:18:27 GMT

Hi @PGN ,

I assume your scenario is as follows:

Database A
Table A: Delete ID=1 --> applied as a DELETE on Table C

Database B
Table B: Insert ID=1 --> applied as an INSERT on Table C

Your expectation:
On the Target Database, first process Delete ID=1 and then Insert ID=1

However, this sequence may not work as expected because the handling processes of Database A, Database B, and the Qlik Replicate tasks are independent. As a result, the INSERT id=1 may be processed before the DELETE id=1, depending on task execution order and replication timing.

Regards,
Desmond

Re: Archive Process ... Two sources One Target

john_wang — Wed, 21 Jan 2026 03:01:12 GMT

Hello @PGN ,

In addition to @DesmondWOO ’s comment, I’d like to propose another option:

We can use two separate tasks to replicate the tables:

Source table A → target table A′
Source table B → target table B′

Then, on the target side, join tables A′ and B′ to produce table C for example using a VIEW.

With this approach, the two replication tasks are independent, making them easier to manage, monitor, and control, and issues in one task will not impact the other.

Hope this helps.

John.

Re: Archive Process ... Two sources One Target

PGN — Thu, 22 Jan 2026 19:11:00 GMT

Hi. Thanks for the replies. These are pretty much the scenarios we came up with. Just doing a sanity check.

Regarding the two independent tasks, we thought of holding the inserts back until after the deletes are done. The issue there is that it's going to have to be managed manually and we would not be able to do any of the SQL replication tool data integrity checks between the source and targets.