How to fix Error 4946 on Windows Server 2025 / Windows 11

Troubleshooting Guide: Error 4946 – ALTER TABLE SWITCH Persistent Attribute Mismatch

Why This Error Happens

This error occurs when the source and target tables in an ALTER TABLE...SWITCH operation have a column defined with mismatched computed column persistence settings — specifically, one table has the column marked as PERSISTED while the corresponding column in the other table is not, or vice versa. SQL Server enforces strict schema parity between partitions involved in a switch operation, and persistence is a metadata-level attribute that must match exactly, even if the underlying computation and data type are identical. This commonly happens when tables are created at different times, by different scripts, or when one table was altered after initial creation without updating its partition-switch counterpart.

Step-by-Step Resolution Guide

Step 1: Identify the Conflicting Column and Tables

  • Run the failing ALTER TABLE...SWITCH statement again and capture the full error text, which includes the column name and both table names.
  • Query sys.computed_columns for both the source and target tables to inspect the is_persisted flag:
  SELECT name, definition, is_persisted 
  FROM sys.computed_columns 
  WHERE object_id = OBJECT_ID('YourSourceTable');
  • Repeat the same query for the target table to compare values side-by-side.

Step 2: Align the Persistence Attribute

  • Determine which table has the “correct” or desired persistence setting based on your indexing and performance requirements.
  • Drop and recreate the computed column on the mismatched table to match the other, using PERSISTED explicitly if needed:
  ALTER TABLE YourTargetTable DROP COLUMN YourComputedColumn;
  ALTER TABLE YourTargetTable ADD YourComputedColumn AS (Expression) PERSISTED;
  • If the column is indexed, drop the dependent index first before altering the column, then recreate the index afterward.

Step 3: Rebuild Indexes and Statistics

  • After recreating the column, rebuild any indexes that referenced it to avoid fragmentation or stale statistics:
  ALTER INDEX ALL ON YourTargetTable REBUILD;
  • Update statistics on the affected table to ensure the query optimizer has current data:
  UPDATE STATISTICS YourTargetTable;

Step 4: Re-run the SWITCH Operation

  • Execute the original ALTER TABLE...SWITCH statement again in a test or staging environment first.
  • Confirm no other schema mismatches (such as data type, nullability, or collation) are reported in subsequent error messages.

Alternative or Verification Steps

  • Verify the fix by re-querying sys.computed_columns on both tables to confirm is_persisted values now match exactly, then re-execute the switch in production during a maintenance window.
  • If recreating the column is not feasible due to downstream dependencies, consider using a staging table with matching schema as an intermediary, then switch into that staging table before merging data via INSERT...SELECT instead of a partition switch.