CDC Extended DDL Handling in SQL Server 2022 and 2025

I pay attention to settings that appear in a procedure signature before they are ready to use. A metadata-based script can include them accidentally, even when the documentation says they are unsupported.

A puzzled woman DBA holds a camera remote beside a tripod whose switch is blocked by a small red stop sign, facing a table of stacked blocks and a robot arm.

This post is part of the Undocumented Changes in SQL Server 2022 and 2025 series. The contents page lists every part in order.

The CDC finding came from three earlier posts: the SQL Server 2022 changed-procedures post, the SQL Server 2022 undocumented DMVs post, and the SQL Server 2025 changed-procedures post. Change data capture (CDC) records data manipulation language (DML) changes from the transaction log. Data definition language (DDL) changes are schema changes such as ALTER TABLE ADD COLUMN.

SQL Server 2022 added an @enable_extended_ddl_handling parameter to sys.sp_cdc_enable_table. It also added sys.fn_cdc_is_ddl_handling_enabled, an undocumented scalar function that appears to read the CDC metadata flag. SQL Server 2025 kept those pieces and added tracing around the internal worker call.

I wanted to know whether the option did anything visible on my SQL Server 2025 test instance, or whether it was only a disabled hook.

The definition trail

In my SQL Server 2019 definition file, sys.sp_cdc_enable_table ended at @allow_partition_switch:

In the SQL Server 2022 definition file, the procedure had one more parameter and passed it to the internal worker:

The same 2022 body rejects the option unless an internal feature switch allows it:

I did not find sys.fn_cdc_handle_ddl_featureswitch_is_enabled in the definition inventory, and a direct call by that name on the test instance failed with Cannot find either column "sys" or the user-defined function or aggregate "sys.fn_cdc_handle_ddl_featureswitch_is_enabled", or the name is ambiguous. The procedure can still reference it internally, so I treated it as an internal hook rather than a user-callable function.

SQL Server 2022 also added this scalar function:

The CDC function reads cdc.change_tables.is_enable_extended_ddl_handling. In my test database, that column was not present in cdc.change_tables, which mattered later.

sys.sp_MScdc_logddl changed in the same 2019 to 2022 window. The 2022 and 2025 definitions add two parameters and pass them to sys.sp_cdc_logddl_internal:

SQL Server 2025 did not change those two parameters again in my files. The 2025 change in this area is around sys.sp_cdc_enable_table: it adds an EngineEdition 12 error branch and trace-event calls around the internal worker.

What Learn says

The live Learn page for sys.sp_cdc_enable_table includes the parameter in the syntax block. Its full argument description is short: “Identified for informational purposes only. Not supported. Future compatibility is not guaranteed.”[1]

The warning matters. The parameter is in a documented procedure signature, but Microsoft does not support using it.

I also searched the SQL Server, Azure and Fabric documentation repositories for the CDC names in this post. I found the sp_cdc_enable_table page and error-message entries for 22874 and 22875. I did not find documentation for sys.fn_cdc_is_ddl_handling_enabled, sys.fn_cdc_handle_ddl_featureswitch_is_enabled, sys.sp_MScdc_logddl, @fis_add_drop_column, or @new_change_table_prefix by whole-word fixed-string search, then by case-insensitive follow-up when the first search found nothing.[2]

The test script

This script is the version I used after one first attempt proved that cdc.change_tables.is_enable_extended_ddl_handling was not a selectable column in the test database. It creates and keeps the scratch database undoc_spinoff_cdc. It creates objects and enables CDC, so it is not read-only. Run it only on a test instance, once, because the table names are fixed. The script does not change server settings, and it leaves the scratch database in place.

What happened on the 2025 instance

I tested this on one SQL Server 2025 CU9 instance, build 17.0.5005.3, Enterprise Developer Edition. SQL Server Agent was stopped, with startup type Manual.

The result matched the Learn page. Microsoft says, “SQL Server Agent doesn’t have to be running when CDC is enabled for a table. However, the capture process doesn’t process the transaction log and write entries to the change table unless SQL Server Agent is running.”[3] Enabling CDC on the database worked. Enabling CDC on the default table also worked, although SQL Server printed four messages saying SQL Server Agent was not running and could not be notified.

Enabling the second table with @enable_extended_ddl_handling = 1 did not work:

sys.all_parameters showed one input parameter for sys.fn_cdc_is_ddl_handling_enabled, plus the return value:

The test database’s cdc.change_tables object had 13 columns. It did not have is_enable_extended_ddl_handling:

Calling sys.fn_cdc_is_ddl_handling_enabled for the one capture instance failed because the metadata column was not there:

After ALTER TABLE ADD AddedAfterCdc int NULL, the source table had the new column. The CDC change table did not. The extended table also had the new source column, but it had no capture instance because the extended enable call failed.

cdc.ddl_history returned no rows for either source object in this test. With SQL Server Agent stopped, I did not get capture-job processing, and I did not change any server setting to make it run.

What I am taking from it

On this SQL Server 2025 CU9 instance, the feature switch rejected the option when I tried to enable it. The public procedure accepted the parameter name, but it rejected 1. The undocumented function existed and exposed one @object_id int parameter, but it failed in the enabled CDC database because the metadata column it references was absent.

I’m leaving @enable_extended_ddl_handling out of generated setup scripts unless Microsoft changes the support statement and the runtime path. If a script generator includes every visible parameter from sys.sp_cdc_enable_table, it can generate a call that fails with error 22874. I plan to leave @enable_extended_ddl_handling out of generated setup scripts unless Microsoft changes the support statement and the runtime path.

If you have tested CDC extended DDL handling on SQL Server 2022 or 2025, or found a public support statement, tell me on Bluesky or LinkedIn, and I’ll update the notes.

References

  1. sys.sp_cdc_enable_table (Transact-SQL) - Microsoft Learn. Documents the CDC enable procedure, the unsupported @enable_extended_ddl_handling wording, and the SQL Server Agent note. ↩
  2. MicrosoftDocs/sql-docs, MicrosoftDocs/azure-docs and MicrosoftDocs/fabric-docs - GitHub. Markdown source repositories searched with whole-word fixed-string git grep and case-insensitive follow-up on 2026-09-26. ↩
  3. sys.sp_cdc_enable_table (Transact-SQL) - Microsoft Learn. Source of the SQL Server Agent statement quoted in the runtime test section. ↩