Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi Team,
We are using IBM DB2 as a source and Google big query as a target, so for testing we only selected 1 table which not contain PK , similar table structure has been created at target, but in replicate it is showing us as a key.
what is the reason behind this ? How it works exactly ?
Thanks & Regards,
Megha
Hello Megha @Megha_More ,
Thanks for your update.
Qlik Replicate is a log-based CDC product. It reads data changes from DB2i Journal.
In DB400, only physical tables' ( type PF) changes are recorded in DB400 Journal; the logical tables (LF) is a view of the PF, it cannot be journaled, so no changes are available in Journal for CDC products, includes Qlik Replicate.
In short,
PF - can be included into a task, with Full load and/or CDC options enables
LF - can be included into a Full Load ONLY task
Qlik Replicate treat the PF and LF as different objects. So the metadata cannot be shared between them. That means , the LF's PK is invisible when we access the PF even their metadata is 'similar'.
I still do not see what's your exact doubts. please share samples (screenshot, or table DDL etc) to help us understand the issue.
Regards,
John.
Hello @Megha_More ,
Thanks for reaching out to Qlik Community!
One of the possibilities is that in DB400 source endpoint, the 1st or 2nd RRN option was chosen, for example:
Then the column RRN will be created as PK for all tables. Not sure if your PK is RRN or other columns?
Hope this helps.
John.
Hi @john_wang ,
In DB2, there are logical and physical tables. We are fetching physical tables, which don't have PK, but in logical tables there are PK. In the replicate console, it shows PK, which is for logical tables.
Eg,
Table A is in physical tables, and Table A_PF is in logical tables. Both tables have the same structure; the only difference is that PK is defined only for logical tables. In the task, we fetch physical tables, but only in the replicate console does it show PK defined, which is the same as logical tables.
Thanks,
Megha
Hello Megha @Megha_More ,
Thanks for your update.
Qlik Replicate is a log-based CDC product. It reads data changes from DB2i Journal.
In DB400, only physical tables' ( type PF) changes are recorded in DB400 Journal; the logical tables (LF) is a view of the PF, it cannot be journaled, so no changes are available in Journal for CDC products, includes Qlik Replicate.
In short,
PF - can be included into a task, with Full load and/or CDC options enables
LF - can be included into a Full Load ONLY task
Qlik Replicate treat the PF and LF as different objects. So the metadata cannot be shared between them. That means , the LF's PK is invisible when we access the PF even their metadata is 'similar'.
I still do not see what's your exact doubts. please share samples (screenshot, or table DDL etc) to help us understand the issue.
Regards,
John.
Hi @john_wang ,
In above image ,keys are defined for input which is not in my source tables (physical tables), this keys are for logical tables.
So my question, why it is shows in replicate side. Is this affecting the task CDC ?
Thanks,
Megha
Hello @Megha_More ,
There are many ways to check the physical file PK information, for example run a command like
DSPFD APSUPDB/KIT
where APSUPDB is the library name, KIT is the physical file name. The PK field information like:
The field ID is the PK, it shows up in Qlik Replicate:
Let's compare the metadata and understand what's the gap.
Regards,
John.
Hi @john_wang ,
We checked same thing, there is no PK in PF still we able to see PK info in replicate console, as those PK are for the LF.
Regards,
Megha
Hi @Megha_More ,
Thanks for the update however it's hard to understand the issue. Please open a support ticket with above same information, support team will help further on the issue.
Regards,
John.