Limitations and considerations

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

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

• If the target table contains columns that do not exist in the source table, these columns need to be defined as NULL or NOT NULL WITH DEFAULT, regardless of the change processing mode defined for the task.

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

• During Full Load, any changes to the source tables are cached and applied or stored (depending on the task definition) after Full Load completes. Limitations related to cached changes are as follows:

  • Cached changes might be duplicated if the target table does not have a Unique Index.

  • After Full Load completes, the cached changes will be applied to the target tables or stored (depending on the task definition), only after a change is done to one of the source tables.

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

• Replication of source tables that contain two columns with the same name, but in different cases (e.g. ADDRESS and address), is not supported.

• Replicate does not capture DDLs of type ALTER TABLE that change a column type from VARCHAR to CHAR. However any change to the size will be captured. Additionally, Replicate will only capture DDLs of type ALTER TABLE that change a column type from CHAR to VARCHAR if the size has changed.

  Example:

  • Change VARCHAR(20) to CHAR(20) - No change in target
  • Change VARCHAR(20) to CHAR(55) - Target will be VARCHAR(55)
  • Change CHAR(20) to VARCHAR(20) - No change in target
  • Change CHAR(20) to VARCHAR(55) - Target will be VARCHAR(55)