`dotnet ef migrations script --idempotent` from migration 0 stopped at
AddSiteIdToDataConnections (Msg 207 'SiteId') and, past it, hit Msg 156/178/137
on MigrateParametersToJsonSchema's CREATE FUNCTIONs and Msg 207 on the
ExecutionId / ParentExecutionId filtered indexes. Same root cause as #126: the
script compiles a whole migration as one batch behind IF ... BEGIN guards.
(The Msg 1911 'Category' / later @legacy errors in the issue were cascades of
those failures and disappear once they are fixed.)
- New MigrationSql.Deferred(sql): wraps a body in EXEC(N'...') with quotes
doubled, so it compiles at execution time as its own batch. Migrate() runs
the identical text.
- Deferred: AddSiteIdToDataConnections step 3 (data move + cursor, DECLAREs kept
in the same body); MigrateParametersToJsonSchema's three CREATE FUNCTIONs and
the UPDATE that calls them; AddAuditLogExecutionId / AddAuditLogParentExecutionId
filtered partition-aligned indexes. No model/snapshot change.
- IdempotentMigrationScriptTests: new IdempotentScript_FromEmpty_RunsClean_AndMatchesMigrate
runs the full script on an empty DB batch by batch, re-runs it as a no-op, and
compares a schema snapshot (columns, defaults, indexes incl. filter + data space,
FKs, checks, modules, principals, permissions, partitioning, per-table row
count + checksum) against a Migrate()-built DB. Fails on the unfixed
migrations with Msg 207 'SiteId'. Batch failures now name the migration.
Schema equivalence: Migrate() before vs after this change, and the fixed
from-empty script, all produce byte-identical snapshots (939 lines); the
57->head script still runs clean and lands on the same snapshot; the seeded
data path through AddSiteIdToDataConnections + MigrateParametersToJsonSchema
gives identical rows via the fixed script and the unfixed Migrate().
Co-Authored-By: Claude <noreply@anthropic.com>
`dotnet ef migrations script --idempotent` puts each migration in ONE batch
behind IF NOT EXISTS guards, and SQL Server compiles the whole batch before any
guard runs. AddAuditLogHashChain adds ChainSeq and then creates two filtered
indexes whose WHERE clause references it in the same batch, so the script
failed with Msg 207 "Invalid column name 'ChainSeq'" on any DB at migration
<= 60 (the 2026-11-11 vd03 deploy hand-inserted GO separators instead).
- AddAuditLogHashChain: the two CREATE INDEX statements go through EXEC(N'...')
so they compile at execution time. Same indexes, same snapshot; Migrate() /
database update unaffected; DBs that already ran the migration never run it
again. The column-level GRANT compiles fine (checked at execution).
- Audit of 58-64: no other migration hits the pattern (the idempotent script
from 57 now runs clean end to end; AddConfigGraphRowVersions' plain CREATE
INDEX on a new column is not compile-checked).
- docs/plans/sql/AddAuditLogHashChain.sql: same EXEC wrap. It, and
PrefixSearchIndexes.sql / AddConfigGraphRowVersions.sql, also carried a
stray UTF-8 BOM after the prepended header comment that made sqlcmd fail
with Msg 102 on line 1 of the batch; removed.
- New IdempotentMigrationScriptTests: migrates the fixture DB to 57, runs the
generated idempotent script batch by batch, asserts every migration applied,
then re-runs it as a no-op. Fails with Msg 207 without the migration fix.
Co-Authored-By: Claude <noreply@anthropic.com>
Joseph Doherty