DELTA_CREATE_TABLE_WITH_DIFFERENT_PROPERTY error on Databricks target endpoint

[raffaelec]

Hello,

I’ve configured a Log Stream task to read from a Microsoft Azure SQL database, along with a replication task that reads from this Log Stream and replicates data to a Databricks Lakehouse (Delta) endpoint.

Both tasks were running correctly until this week, when I stopped and resumed them for maintenance on the Qlik Replicate server.

After resuming the tasks, the replication task started logging the following error for all tables, and replication is now suspended for each of them:

Failed (retcode -1) to execute statement: CREATE OR REPLACE  TABLE `schema_name`.`table_name` ([fields]) USING DELTA LOCATION 'abfss://location_for_tables' TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true)
RetCode: SQL_ERROR  SqlState: 42KD7 NativeError: 80 Message: [Simba][Hardy] (80) Syntax or semantic analysis error thrown in server while executing query. Error message from server: org.apache.hive.service.cli.HiveSQLException: Error running query: [DELTA_CREATE_TABLE_WITH_DIFFERENT_PROPERTY] com.databricks.sql.transaction.tahoe.DeltaAnalysisException: The specified properties do not match the existing properties at abfss://location_for_tables.

== Specified ==
delta.autoOptimize.optimizeWrite=true

== Existing ==
delta.autoOptimize.optimizeWrite=true
delta.enableChangeDataFeed=true

The Databricks target endpoint is configured with the internal parameter $info.query_syntax.create_table, using the following statement:

CREATE or REPLACE ${TABLE_TYPE} TABLE ${QO}${TABLE_OWNER}${QC}.${QO}${TABLE_NAME}${QC} ( ${COLUMN_LIST} ) USING DELTA TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true)

I then tried adding the missing property to match the existing table metadata, but the same error still occurs. Specifically, I tested the following statement:

CREATE or REPLACE ${TABLE_TYPE} TABLE ${QO}${TABLE_OWNER}${QC}.${QO}${TABLE_NAME}${QC} ( ${COLUMN_LIST} ) USING DELTA TBLPROPERTIES (delta.enableChangeDataFeed=true, delta.autoOptimize.optimizeWrite = true)

I even tried removing the internal parameter entirely, but the same error continues to occur.

Is there a supported way to force Qlik Replicate to recreate the tables (or align with existing ones) while preserving or explicitly setting the missing property?

Any guidance or best practices for handling this scenario with Databricks targets would be greatly appreciated.

Thank you very much in advance for your help.

Best regards

[john_wang]

Hello @raffaelec ,

Thanks for the post!

I’m not sure which versions of Qlik Replicate and Databricks you’re currently running. However, you can follow the steps below to troubleshoot the issue:

1. Create a test task to replicate a table from LogStream to a Databricks test table (this will not impact existing tables).

2. Set TARGET_LOAD and TARGET_APPLY to Verbose in the task, then reproduce the issue.

3. Review the task log files (please do not forget to decrypt the verbose task log files) to identify the target table creation SQL statement. Try running that SQL manually in the Databricks web UI to see whether the same error occurs, or to determine the correct SQL syntax, or figure out the root reason of the failure.

Feel free to let us know if you need any further assistance.

Good luck,

John.

[john_wang]

Hello @raffaelec ,

Could you please confirm whether the following is correct?

1. The tables were initially created without the below property

   TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true)

2. The property was added later, and then you attempted to resume the tasks.

If so, you have several options to resolve this:

Option 1: Don’t recreate the table — alter it

If the table already exists and you only need to change its properties:

ALTER TABLE schema_name.table_name
SET TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true);

Option 2: Drop the table and recreate it

If you prefer a clean rebuild:

DROP TABLE IF EXISTS schema_name.table_name;

Then run the CREATE TABLE statement again.

Option 3: Use IF NOT EXIST

If this is only for initialization and you want to avoid recreating existing tables:

CREATE TABLE IF NOT EXISTS schema_name.table_name
USING DELTA
LOCATION 'abfss://location_for_tables'
TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true);

Hope this helps.

John.

[raffaelec]

Hello @john_wang,

Thank you for your response.

The tables were originally created using the internal parameter
$info.query_syntax.create_table, with the following statement:

CREATE or REPLACE ${TABLE_TYPE} TABLE ${QO}${TABLE_OWNER}${QC}.${QO}${TABLE_NAME}${QC} ( ${COLUMN_LIST} ) USING DELTA TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true)

This means that, according to this internal parameter, the tables were created with this property

delta.autoOptimize.optimizeWrite = true

but without this property

delta.enableChangeDataFeed = true

I'm not sure when and how this property was added to the tables.

Unfortunately, I don’t have direct access to the target tables in Databricks, so I'm unable to manually drop, recreate or alter them. From a SQL perspective, the correct table definition should include both the table properties:

delta.autoOptimize.optimizeWrite = true
delta.enableChangeDataFeed = true

As suggested, I increased the logging verbosity. However, the logs still only show the following error and do not provide any additional details:

00018296: 2025-12-15T23:58:05:117065 [TARGET_LOAD ]T: Execute create table statement failed, statement CREATE OR REPLACE TABLE `schema_name`.`table_name` ([fields]) USING DELTA LOCATION 'abfss://location_for_tables' TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true) [1022502] (cloud_imp.c:5611)
00018296: 2025-12-15T23:58:05:117065 [TARGET_LOAD ]T: Handling new table 'schema_name'.'table_name' failed [1022502] (endpointshell.c:3188)
00018296: 2025-12-15T23:58:05:117065 [TARGET_LOAD ]E: Failed (retcode -1) to execute statement: CREATE OR REPLACE TABLE `schema_name`.`table_name` ([fields]) USING DELTA LOCATION 'abfss://location_for_tables' TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true) [1022502] (ar_odbc_stmt.c:5069)
00018296: 2025-12-15T23:58:05:117065 [TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: 42KD7 NativeError: 80 Message: [Simba][Hardy] (80) Syntax or semantic analysis error thrown in server while executing query. Error message from server: org.apache.hive.service.cli.HiveSQLException: Error running query: [DELTA_CREATE_TABLE_WITH_DIFFERENT_PROPERTY] com.databricks.sql.transaction.tahoe.DeltaAnalysisException: The specified properties do not match the existing properties at abfss://location_for_tables.

== Specified ==
delta.autoOptimize.optimizeWrite=true

== Existing ==
delta.autoOptimize.optimizeWrite=true
delta.enableChangeDataFeed=true

I also tried creating a new replication task using a new Databricks target endpoint (a copy of the original one affected by the issue), but I still encounter the same error for the same SQL statement, even during the initial task startup and even when the internal parameter includes both properties in the table creation statement.

Best regards

[john_wang]

Hello @raffaelec ,

The default value of delta.enableChangeDataFeed is false.

If it is set to true, the table has been altered (or was created) with this property enabled. You can check who enabled it and when by reviewing the table history. For example:

describe history johnw_qmi_unitycatalog.default.kit;

In the output, look for:

• the timestamp

• userId / userName

• the operation (for example, SET TBLPROPERTIES)

• the operationParameters containing delta.enableChangeDataFeed

Hope this helps.

John.

[raffaelec]

Hello @john_wang,

Thank you again for your suggestions.

I have another question related to the same topic.

As mentioned earlier, I don’t have access to the target Databricks environment. Therefore, I cannot manually recreate the tables in Databricks or in the Data Lake. I would like to add the property delta.enableChangeDataFeed=true during table creation directly from the Qlik Replicate endpoint.

If I understand correctly, the proper way to set table properties at creation time is by using the internal parameter $info.query_syntax.create_table. I tried to add this property by setting the following value for that parameter:

CREATE or REPLACE ${TABLE_TYPE} TABLE ${QO}${TABLE_OWNER}${QC}.${QO}${TABLE_NAME}${QC} ( ${COLUMN_LIST} ) USING DELTA TBLPROPERTIES (delta.enableChangeDataFeed=true, delta.autoOptimize.optimizeWrite=true)

However, the CREATE operation executed by Qlik Replicate always omits the newly added property and continues to use the value that was configured for the internal parameter a long time ago. Specifically, the operation being executed is:

CREATE or REPLACE ${TABLE_TYPE} TABLE ${QO}${TABLE_OWNER}${QC}.${QO}${TABLE_NAME}${QC} ( ${COLUMN_LIST} ) USING DELTA TBLPROPERTIES (delta.autoOptimize.optimizeWrite=true)

This makes me suspect that Qlik Replicate is not correctly registering the updated value of the internal parameter. After updating the parameter, I save the new endpoint configuration and then start the reload. I’m not sure if I’m missing an additional step.

I also tried recreating the replication task using a new endpoint, but the result is the same: the executed operation is always CREATE or REPLACE without the delta.enableChangeDataFeed=true property.

Finally, I tried to remove the internal parameter entirely, but during the task reload Qlik Replicate still executes CREATE or REPLACE without the delta.enableChangeDataFeed=true property. This result also seems unexpected to me, since (if I’m not mistaken) the default table creation operation should be CREATE, not CREATE or REPLACE, when no custom syntax is defined.

For reference, I’m using the November 2025 version of Qlik Replicate and the Simba Spark ODBC Driver version 2.9.2.

Thank you in advance for any help you can provide.

Best regards

[john_wang · Accepted solution]

Hello @raffaelec ,

The reported behavior cannot be reproduced in my lab using Qlik Replicate 2025.11.0.164 GA with Simba Spark ODBC Driver version 2.9.2.1008. There is also no caching of internal parameters in Qlik Replicate.

To proceed with a deeper investigation, I recommend opening a support ticket so we can analyze the issue in more detail.

Regards,

John.