DDL changes on DB2 LUW

Abrie_M — Thu, 28 Apr 2022 11:45:06 GMT

Good day

From the Replicate documentation:

When the Change table option is enabled in the Store Changes Settings tab, the first timestamp record in the table may be Zero in some cases (i.e. 1970-01-01 00:00:00.000000)

I've also found that when a CDC task is stopped and resumed, the first DDL record also have the 1970 timestamp. This means that Compose does not pick up the DDL changes.

As it is normal behavior for tasks to be stopped/resumed (server maintenance, etc), would one assume that CDC with schema evolution does not work for a DB2 LUW endpoint?

Anyone found a workaround for this?

Thanx

Abrie

Re: DDL changes on DB2 LUW

SwathiPulagam — Thu, 28 Apr 2022 12:19:10 GMT

@Abrie_M For some sources(like DB2 LUW and Postgres etc.,), Replicate can't capture the exact timestamp( due to source limitations) when we start the task for the first time or stop and resume the task. So Replicate record that uncaptured time stamp as 1970-01-01 00:00:00.000000.

The good news is that Replicate overcome this issue for the Postgres source by adding the last commit timestamp to the stream position and we can provide a workaround how to handle the remaining situations where the replicate still maintains the timestamp as 1970-01-01 00:00:00.000000.

If you create a case listing the problems then R&D will revisit DB2 source limitations related to these timestamp issues.

Thanks,

Swathi

topic Re: DDL changes on DB2 LUW in Qlik Replicate

DDL changes on DB2 LUW

Re: DDL changes on DB2 LUW