Unable to replicate due to encrypted error

[desmondchew]

We are setting up a new task to replicate from source Azure SQL Server into target endpoint SQL Server 2024.

The task ran but none of the tables get replicated. We hit into the following errors.

Table 'dbo'.'table1' has encrypted column(s), but the 'Capture data from Always Encrypted database' option is disabled. The table will be suspended.

Can share how to fix this please?

Thank you.
Desmond

[Dana_Baldwin]

Hi @desmondchew 

Which version of Qlik Replicate are you using? I see a documented fix for this issue in version 2024.11.0.620 (and later). This may or may not be the root cause of the error in your situation.

Thanks,

Dana

[korsikov]

Therefore, there is an undesirable scenario:

After a failover, Replicate again incorrectly treats regular columns as encrypted.

May 2026 does not stop the table.

The table continues to operate, but some columns may disappear from the target.

In other words, May 2026 potentially transforms a noticeable “suspended” error into a less noticeable loss of columns. Always Encrypted remains an unsupported feature of MS-CDC;

[DesmondWOO]

Hi @desmondchew ,

From my understanding, "Decrypt Always Encrypted columns" feature is supported only on MS SQL Server endpoint.

Regards,
Desmond

[korsikov]

After upgrading Qlik Replicate from November 2024 to May 2026 and installing Microsoft ODBC Driver 18, we encountered a serious issue with a Microsoft SQL Server MS-CDC source.

The source tables contain a _Version column defined as:

_Version timestamp NOT NULL

The corresponding target column is:

_Version varbinary(8) NOT NULL

Before the upgrade, these tables were replicated normally.

After upgrading to May 2026, INSERT operations started failing on the target with:

A data error was encountered. Refer to the 'attrep_apply_exceptions' table for details.

RetCode: SQL_ERROR
SqlState: 23000
NativeError: 515

Cannot insert the value NULL into column '_Version';
column does not allow nulls. INSERT fails.

Initially, this looked like a source data issue. However, we verified that there are no NULL values in the source table.

More importantly, the SQL Server CDC change table contains the correct _Version values.

For example:

__$operation = 2  INSERT
_Version      = 0x000000002CD88273

__$operation = 3  UPDATE BEFORE
_Version      = 0x000000002CD88273

__$operation = 4  UPDATE AFTER
_Version      = 0x000000002CD88275

So SQL Server CDC is capturing the column correctly.

However, in the Qlik Replicate Store Changes (__ct) table, the same events contain:

INSERT  _Version = NULL
UPDATE  _Version = NULL

The target table therefore never receives the INSERT because _Version is NOT NULL.

We then enabled detailed Replicate logging and found the most important part of the issue.

Replicate itself generates a SELECT against the SQL Server CDC table similar to:

SELECT
    ct.[__$operation],
    ...
    ct.[_IDRRef],
    ct.[_Marked],
    ct.[_PredefinedID],
    ...
FROM [cdc].[dbo__R18_CT] ct

The _Version column is completely missing from the SELECT generated by Replicate.

It should contain:

ct.[_IDRRef],
ct.[_Version],
ct.[_Marked],

but Replicate May 2026 generates:

ct.[_IDRRef],
ct.[_Marked],

Therefore, the value is not lost by SQL Server CDC and it is not converted to NULL by the ODBC driver.

The column is already excluded from the CDC query generated internally by Qlik Replicate.

The generated target INSERT also completely excludes _Version:

INSERT INTO dbo.Spr_Kontragentyi_Reference18
(
    [_IDRRef],
    [_Marked],
    ...
)
VALUES (...)

As _Version VARBINARY(8) is NOT NULL on the target, SQL Server correctly rejects the INSERT.

Why this is concerning

According to the Qlik Replicate documentation, SQL Server TIMESTAMP is a supported datatype and is mapped to Replicate BYTES.

The column is also not encrypted.

Nevertheless, after upgrading to May 2026, Replicate appears to silently exclude this non-encrypted TIMESTAMP/ROWVERSION column from MS-CDC processing.

There is no suspension or clear warning indicating that the column has been removed from replication.

This creates a significant data integrity risk:

• CDC continues running;
• Store Changes records continue being generated;
• _Version silently becomes NULL;
• INSERTs into targets with NOT NULL constraints fail;
• if the target allows NULL, replication could potentially continue with incorrect/incomplete data without an obvious failure;
• downstream DWH processing can therefore receive incomplete data or miss records entirely.

This is especially concerning because May 2026 introduced changes to MS-CDC column handling and handling of encrypted columns.

We previously also observed false "Always Encrypted" detection in the same environment, although _Version itself is not an encrypted column.

Environment

• Source: Microsoft SQL Server, MS-CDC
• Source datatype: timestamp NOT NULL
• CDC datatype: binary(8)
• Target: Microsoft SQL Server
• Target datatype: varbinary(8) NOT NULL
• Qlik Replicate before upgrade: November 2024
• Qlik Replicate after upgrade: May 2026
• Microsoft ODBC Driver: 18
• Store Changes enabled

At this point, our planned recovery is to roll back Replicate to the previous working version and replay CDC from the source LSN from before the May 2026 task was started, while the corresponding source CDC records are still available.

Has anyone seen this behavior with SQL Server TIMESTAMP/ROWVERSION columns after upgrading to Qlik Replicate May 2026?

Is this a known May 2026 regression in the new MS-CDC column handling logic?