Documentation

for SQL Delta

sqldelta.com

SQL Delta Help

Command Line

SQL Delta can run projects without user interaction by passing one or more saved project names, or project file paths, on the command line. This is the normal entry point for Task Scheduler and other unattended automation.

Recommended setup

  1. Create and save the project interactively first, including all connection details, compare options, and any passwords you expect the build to retain.
  2. Use the relevant On Completion, Data Compare On Completion, or Schema View On Completion page to configure the outputs you want after a run, such as scripts, reports, snapshots, email, or log files.
  3. Test the project manually before relying on quiet automation, especially if the workflow can generate or execute scripts.

Create a shortcut to SQLDelta.exe and add the saved project name to the target. If the project name has spaces then enclose the project name in quotes. Multiple projects can be added to the command line.

For example: ...\SQLDelta.exe "My CLTest"

Opening that shortcut will immediately run the compare for the saved project.

Command Line Options

The current built-in help reports the supported syntax as:

sqldelta.exe "project name"|"...\filename.xdp" [/L[:0..3]] [/M[:n]] [/Q[:0..3]] [/R] [/SS:...] [/TS:...]

To run a group asynchronously, use the bracketed form:

sqldelta.exe ["Project A","Project B"] /Q:2

  • "project name" runs a saved project from the Project Manager list. A bare project argument runs the compare workflow.
  • "filename.xdp" loads a project file directly. Include the path if the file is not in the default project folder.
  • Multiple plain project names or filenames can be supplied and are processed one after another. Use [...] when you explicitly want asynchronous execution of project names or project-file entries.
  • /R automatically runs the deployment script after compare. Without /R, command-line execution stops after the compare and any active On Completion steps.
  • /Q[:0..3] runs quietly and also implies fallback logging at the same level. /Q by itself behaves as /Q:1.
  • /L[:0..3] writes the fallback log without enabling quiet mode. Level 0 is brief, 1 is normal, 2 is verbose, and 3 is currently reserved.
  • /M[:n] forces SQL Delta to open on the primary monitor or a specific monitor number.
  • /SS, /SU, /SP, /SD override the source server, user, password, and database. /TS, /TU, /TP, and /TD do the same for the target connection.

The built-in help also exposes maintenance switches such as /? for help, /r:regcode for registration, /X:activation or /X for activation or deactivation, /x to exit after those licensing actions, and /@ for internal testing. Those are not part of the normal unattended compare workflow.

Older help examples and internal notes may still mention /A to run all checked projects. The current parser help and command-line tests no longer list that switch, so it should not be used for new automation.

Quiet mode and automation safety

Running a project using /Q[:level] does not show the normal results UI. /Q also enables fallback logging at the same level, but unattended runs should still use On Completion events to create the outputs you need. SQL Delta shuts down automatically when the last project and last On Completion event has finished. The Version 6 and Version 7 release notes repeatedly mention improvements to quiet-mode processing, return values, folder handling, and data compare command-line stability, but you should still verify the exact behavior of your installed build before wiring it into production scheduling.

In practice this means:

  • use On Completion events to write scripts, reports, snapshots, or email/log output to predictable locations;
  • test quiet runs with non-production projects first so you can confirm exit codes and post-run artifacts;
  • review any project that can execute change scripts, because quiet mode hides prompts that would otherwise be visible in the UI.

Things to do with Command Line

All of these tasks use On Completion events to perform extra work beyond simply running the project.

  • Run a Schema View project on a schedule and save a snapshot of the database. This gives you a lightweight schema-history trail that can later be used in Schema Compare.
  • Run a Schema Compare project on a schedule, save the sync script to file, and email or archive it for later review.
  • Run a Data Compare project on a schedule, generate the sync script, and optionally execute it to synchronize downstream databases.

Changes from Version 5

In Version 5 the command line process required more manual project editing for useful output. From Version 6 onward, On Completion events are the main way to define what unattended runs should produce.

Older command-line workflows also depended on automatic logging behavior. Current guidance is to configure logging and other automation outputs explicitly per project.