Recent Activity
View allactive reservations, open branches
| ID | Status | Author | Description | Script | Created | Expires | |
|---|---|---|---|---|---|---|---|
| Branch | Ticket | Status | Database | Created | |
|---|---|---|---|---|---|
| Object | Type | Migration | Author | Description | Expires |
|---|---|---|---|---|---|
Deployment Configuration
Configure the reference database, migrations folder, and baseline path for this project.
Port Registry
Central registry of TCP ports in use across all projects on this machine.
Activity Log
Dashboard Deployment Flows
The project detail page shows deployment banners. When there are pending migrations it offers two actions (Confirm Deployment and Generate Script); otherwise only Generate Script is available.
Generate Script
Downloads a self-contained SQL deployment script. Does NOT touch any database.
- Collects migration
.sqlfiles from the project's migrations folder whose filenames match the required pattern0001_name.sql(e.g.,0001_initial_schema.sql); files that do not match are ignored - Generates a single SQL script that includes every discovered migration in deterministic (sorted) order, wrapped in idempotent checks
- Each migration checks
dbo.SchemaVersion— if already applied, it's skipped automatically - Database object definitions (stored procedures, functions, views) are wrapped in
sp_executesqlfor correct batch handling - The script is downloaded as
{ProjectName}_deployment.sql— ready to run in SQL Server tools that supportGObatch separators (e.g., SSMS, Azure Data Studio, sqlcmd)
Note: This is the recommended approach for production deployments. You control when and where the script runs.
Confirm Deployment
Applies all pending migrations directly to the project's reference database. Cannot be undone.
- Shows a confirmation dialog — you must explicitly confirm before anything happens
- Connects to the project's configured reference database
- Reads
dbo.SchemaVersionto determine which migrations are already applied - Executes each pending migration script directly (splits on GO, runs each batch)
- Records each applied migration in
dbo.SchemaVersionwith checksum and timestamp - Stops on first failure — migrations are NOT wrapped in a transaction; if a batch fails, earlier batches from the same migration (and already-applied migrations in that run) remain applied and are NOT rolled back
Note: Use this only against your project's configured reference database (for dev/test/reference environments). For production databases, use Generate Script instead.
Maintenance Actions
Available from the Maintenance section on the project detail page. These operations are irreversible.
Refresh Baseline
Consolidates all applied migrations into the baseline .mdf and deletes the script files. Cannot be undone.
- The project must have a configured baseline
.mdfpath - No open branches may exist — the dashboard disables this button when any feature branch is open
- At least one migration script must exist on disk
- Shows a confirmation dialog — you must explicitly confirm before anything happens
- Creates a temporary database from the current baseline
.mdf - Applies all migration scripts to the temporary database, verifying every one succeeds
- Assigns a version number (format
YYYY.N, e.g.2026.5) and records it indbo.DbVersion - Generates a versioned deployment script and saves it to
../versions/{version}.sql(in aversionsfolder one level above the baseline.mdfdirectory) for archival - Replaces the baseline
.mdfwith the consolidated version (all migrations baked in) - Attempts to drop and recreate the reference database from the updated baseline — if this fails, you may need to recreate the reference database manually
- Deletes migration script files that match the naming pattern (
0001_name.sql) from the migrations folder — other files are left untouched - Resets migration reservations in the coordinator database
Note: After this operation all migration scripts matching the naming pattern are removed and the baseline contains the consolidated history. New branches will start from this state. If a failure occurs before the baseline is replaced, the temporary database is cleaned up and the original baseline is preserved. Failures after the baseline has been replaced may leave some cleanup steps only partially completed.
MCP Tools Reference
All tools available via the MigrationCoordinator MCP server. Agents call these through JSON-RPC at /rpc.