Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hello Qlik Community,
We are currently trying to replicate various tables from a DB2-ZOS to a DB2-LUW using Qlik Replicate, and we have noticed that the nullability in the target table and the corresponding __ct table are different. Are there ways to keep these consistent?
some snippets of the corresponding log:
Hello @VTTR ,
Welcome to Qlik Community forum and thanks for reaching out here!
In DB2 for z/OS (DB2z) or DB2 for Linux, UNIX, and Windows (DB2 LUW), the nullability of columns in the target table should match the nullability of columns in the source table. However, in the corresponding __ct
table, only primary key columns, such as header__change_seq
, are marked as "NOT NULL." All other columns derived from the source table (in DB2z or DB2 LUW) are set as nullable.
The reason for this is that even if a column in the source table is defined as "NOT NULL," its value may not appear in the DB2 transaction log if it hasn't been changed. Most databases omit unchanged columns from the transaction log to optimize logging. In some databases, this behavior is configurable; for instance, in Oracle, non-changed columns can be included in the REDO LOG through full supplemental logging.
Hope this helps.
John.
Hello @VTTR
Have you enabled both "Apply Changes" and "Store Changes" in the task?
I would suggest create a new task with same source and Target and add a problematic table into it with enhanced logs and also add "keepCSVFiles" Internal parameter if supported at the target endpoint and observe the behavior.
Regards,
Suresh
Hi @VTTR ,
I've also noticed that the nullability of the columns in the target table differs from that in the __ct table. The user guide mentions that
"LOB columns are always created as nullable on the target database. If you create the target table(s) manually, then you must set all LOB columns to nullable."
Given this, I recommend submitting a support ticket.
Regards,
Desmond