Limitations and considerations

When working with Qlik Replicate, you should be aware of the following limitations and considderaitons:

• It is not recommended to performing database maintenance tasks during replication as doing so might result in unpredictable behavior.

• Replicate does not support replication of Primary Keys that are LOB data types.

• When replicating a table that has no Primary Key or Unique Index, LOB columns will not be replicated.

• When the Limit LOB size to option is enabled, replication of structured data LOBs (e.g. XML, JSON, IMAGE, etc.) may truncate (and thereby invalidate) the structured data in the target LOB.

• In Batch Optimized Apply mode, if the target table has more columns than the source table, any values in the extra columns will be replaced with NULL.

  The workaround is to create two tasks. One task for the target table(s) with extra columns and the other task for the source table(s) which have the same number of columns as the target tables. Then, run the task for the target table(s) with extra columns in Transactional Apply mode and run the other task (where the target tables do not have extra columns) in Batch Optimized Apply mode. Note, however, that updating large tables in Transactional Apply mode may impact performance.

• When Replicate creates a new table in the target endpoint, it defines only one index on the table. The index will either be the Primary Key or the first Unique Key (according to alphabetical order) of the table. No other indexes will be defined in the target. If additional indexes are required, these will need to be defined manually.

• If a Unique Index/Primary Key in any of the source tables contains NULL values in multiple rows, UPDATE and DELETE operations on one of the rows will UPDATE /DELETE all of the target rows (in the Unique Index/Primary Key) that have a NULL value.

• 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.

• If you stop a task after Full Load completes, make some changes to the source tables, and later resume the task from timestamp (by selecting the Start processing changes from run option), some changes may not be replicated to the target. This usually only happens if the transaction logs in the source database have been deleted due to a log purge policy. In this case, Replicate will resume the task from the last change in the current transaction log.
• When replicating tables without a Primary Key, there is no way to verify whether a record already exists on the target. This may result in data inconsistency when UPDATE and DELETE operations are performed on the target database.

• Replication of calculated values is not supported during Change Processing.

• If a task fails with a recoverable error on the target while it is starting, it will not read changes from the source.
• Cached changes may be duplicated in a target table that does not have a Unique Index.
• A unique index consisting of several ascending and descending columns will always be replicated to the target as ascending columns. In other words, the descending columns will become ascending columns.
• When the source table contains an identity column, Replicate does not create the identity column on the target table. In this case, the table will need to be created manually on the target endpoint.

• Replication of tables with the same name as any of the Replicate Control tables is not supported. For a list of the Control Table names, see Control Tables.

• CREATE TABLE operations performed on the source while a task is stopped will be applied to the target when the task is resumed, but will not be recorded as a DDL in the attrep_ddl_history Control Table.

• Due to access restrictions on Windows registry entries, two installations of Replicate on the same machine must be installed under the same user account. If they are installed under different accounts, only one of the installations will work.

• When using filters that do not contain a Primary Key, DELETE operations will not be captured from endpoints that do not support Before-images. Examples of such endpoints include all PostgreSQL-based sources, Salesforce source, and Oracle source that does not have full supplemental logging on columns included in the filtering condition.