SQL Server upgrade applies no DDL and throws NotImplementedException (ConnectionlessProcessor)

[wabolabs]

Summary

A fresh install of the current release on SQL Server cannot complete its
schema migration. The upgrade worker reports success, but it applies no DDL and
then throws on the first migration that inspects the existing schema:

System.NotImplementedException: Method ConstraintExists is not supported by
the connectionless processor
   at FluentMigrator.Runner.Processors.ConnectionlessProcessor.ConstraintExists(
        String schemaName, String tableName, String constraintName)

The same release migrates cleanly on PostgreSQL, which suggests the SQL Server
code path is invoking the DODBUPGRADE migrations with a
ConnectionlessProcessor — a processor that explicitly cannot answer
Exists() queries, so any migration using them throws.

The failure is deterministic and reproduces in two distinct situations:

1. Upgrade of an existing installation (2022-era database → current).
2. Fresh install on an empty database.

Versions

• Current release (the 4.862.0 Docker images).
• Also reproduced on 4.814.0.

The behaviour is not specific to one build, so it looks like a long-standing
defect in the SQL Server upgrade path rather than a regression.

Expected behaviour

Either:

• the SQL Server upgrade runs against a processor that supports
  Exists() queries, or
• migrations that depend on Exists() are gated/skipped for SQL Server in the
  same way they already appear to be handled for other engines, or
• the upgrade fails loudly with an actionable message instead of a
  NotImplementedException from inside FluentMigrator.

Actual behaviour

Schema.*.Exists() and Constraint(...)?.Exists() calls throw
NotImplementedException, so the migration run aborts partway. Because the
processor is connectionless, the migrations that "succeed" do so without
writing anything — so the database is left partially migrated and the failure
is not obvious from the exit status alone.

Workarounds tried

• Running the upgrade repeatedly — same failure at the same migration.
• Re-running against a completely empty database — same failure. This rules
  out corrupt or partially-migrated data as the cause.
• Switching the database engine to PostgreSQL — all 236 migrations apply
  cleanly (through M0242) and the API is functional, including
  Calls/SaveCall returning 201.

I have not been able to find a supported configuration of the SQL Server path
that completes, so the PostgreSQL path is currently the only one I can deploy.

Notes

• PostgreSQL requires CREATE EXTENSION citext before migrating, since the
  schema uses citext for username/email columns. Not a blocker, but worth
  documenting in the Postgres install docs.
• RESGRID__DataConfig__DatabaseType=1 is required to select the PostgreSQL
  engine; omitting it produces a confusing connection-string error
  (keyword not supported: "host") rather than a clear message.

Happy to provide the full worker log on request.