Benchdog SQL Multi Runner

A list holds databases on any servers, each with its own sign-in: your Benchdog account for Azure SQL, your Windows account for SQL Server on your network, or a SQL login. In VS Code, New List asks for the name and then the databases; the + beside a list adds more, starting on the servers already in it. In the desktop app, Ctrl+N makes a list and Ctrl+E adds databases, where you can also type a database's name.

Lists are kept for next time with each database's server, name and sign-in and how the script runs, never a password. Remove a database from a list, rename the list with F2, or remove the list after a Yes.

benchdog sql run fix.sql --server sqlhost --database Shop --database Shop_Test --windows runs the script on two databases with your Windows account. --all-databases runs it on every database on the server you can see, and --sql-login sa signs in with a SQL login, asking for the password, with --remember-password to keep it in the system's secure store.

The command says how each database went, its messages, and how many columns and rows each result set had. Row values are never printed; --csv results writes them to files in that folder. The exit code is 0 only when every database succeeded.

Turn on Transaction per database, or add --transaction on the command line. Each database's script then runs in one transaction, rolled back when a batch fails or the run is stopped, so a database that fails says The transaction was rolled back, so nothing in this database changed. Without it, a batch that fails still stops the rest of the script in that database, but what ran before it stays.

Stop ends the run: the databases running stop where they are, rolling back their transaction when there is one, and no more start. Those stopped are tagged amber and those that never started grey.

Stop on first error, or --stop-on-error, starts no more databases once one has failed; the databases already running finish. The ones that did not start say Not run: the run stopped after an error in Shop_Archive on localhost.

At a time is how many databases run together, from 1 to 32, 4 by default; on the command line it is --at-a-time 8. Timeout is how long one batch may run, in seconds, and 0 waits as long as it takes; on the command line it is --timeout 30. Both are saved with the list, and in a project file as atATime and timeoutSeconds.

On GO, as SQL Server Management Studio and sqlcmd do: GO on a line of its own, in any case, with a comment after it if you like. GO 5 runs the batch five times. A GO inside a string, a comment or a name in brackets is not a split. In VS Code the script runs as it is in the editor, unsaved changes and all; the desktop app reads the file again on each run, so Edit script and save, then run.

Save as CSV in the Run tab, Ctrl+S in the desktop app, or --csv results on the command line writes the last run's result sets to a folder. When every database returns the same columns, each result set goes in one file, such as result-1.csv, with the server and database first on each row; otherwise each database's result sets get files of their own. The files are UTF-8 with a byte order mark, so Excel opens them. The command line keeps the first 1,000 rows of each result set for the files, or as many as --max-rows says.

Save it as a .multirunner.json project file: Save as Project File... on a list in VS Code, Ctrl+Shift+S in the desktop app, or --save-project shops.multirunner.json on the command line, which writes the file and then runs. The file keeps the list's name, its databases with their sign-ins, the script beside it and how it runs, never a password.

Open it anywhere: Open Project File in VS Code gives IntelliSense, its problems in the Problems panel and an Open List link; Ctrl+O in the desktop app adds its list; benchdog sql run --project shops.multirunner.json runs it, with --stop-on-error or --transaction added for that run.

SQL Server or Azure SQL databases you can sign in to, and nothing installed on them: Benchdog connects as you, lists a server's databases when you ask, and runs the script you give it, batch by batch. A database that can not be reached says why, and the others still run.

Yes. Before a run, the script is read for words that may change data or objects, such as INSERT, UPDATE, DELETE, MERGE, TRUNCATE, DROP, ALTER, CREATE, EXEC, GRANT, BACKUP or SELECT INTO, and a batch that starts with a procedure's name counts as EXEC. Words inside strings and comments do not count. The question names the words found and how many databases the script runs on, such as This script may change data or objects in 4 databases: it uses UPDATE and DELETE., and No runs nothing. A read-only script runs straight away. On the command line, --yes answers the question for you.

Each list's name, its databases' servers, names and how to sign in, and how its scripts run: VS Code keeps them for the extension, and the desktop app in multirunner-desktop.json in the Benchdog folder. A SQL login's password is kept until the app closes, or in the system's secure store only when you tick Remember. Project files never hold a password. Error messages have row values taken out, and the command line never prints row values.

You keep a named list of databases on any servers, each with its own sign-in, and run the script open in your editor on all of them with one click, a few at a time. Each database gets its own outcome, timing, rows changed, messages and result sets, with every error at the line in your script, and a transaction per database when you want all or nothing. The same list and script run again from the desktop app or the command line, and in a scheduled job in Benchdog SQL Scheduler.

Yes. Every tool has a thirty day trial with every feature, and no card. Ask for one at benchdog.dev/trial with your name and email, and the trial licence arrives by email, as a line to paste and a benchdog.licence file. One trial per person covers every tool at once.

One licence is for one person and covers the VS Code extension, the desktop app and the benchdog command, on every machine that person works from. There is no machine limit and no server count. Buying another tool reissues your licence with that tool added.

The licence shows whose it is: your name and email appear in each tool's About and account menu.

The last version released while you were paid keeps working. Only updates stop. A licence is checked offline and never expires a version it covers, so nothing stops working the day your year ends.

The VS Code extensions run in VS Code 1.95 or later on Windows, Linux and Mac. The desktop apps and the benchdog command are single programs for Windows (x64), Mac (Apple silicon) and Linux (x64), with no .NET install needed. The SQL tools work with SQL Server 2017 or later, Azure SQL Database and Azure SQL Managed Instance.

No. The engine runs on your machine, reads your vaults and databases as you, and keeps the results with you. A tool contacts benchdog.dev only when you click something that needs it, such as asking for your licence, and never in the background. Licences are checked offline.

Every change a tool makes runs in one transaction with XACT_ABORT on, so it all happens or none of it does. A SQL Schema Compare deploy, a SQL Data Comparer sync and a SQL Data Filler fill are each one transaction, and SQL Data Scrambler scrambles each table in one. The scripts the tools write for you to run in SSMS or sqlcmd are wrapped the same way and roll back if any batch fails. SQL Multi Runner runs your own script as it is, and wraps each database in a transaction when you tick that. Before any change, a tool says what it will do and asks first: SQL Schema Compare names the tables and columns whose rows go, SQL Data Comparer says how many rows change, and SQL Data Scrambler asks you to type the database's name. SQL Schema Compare also stops if either database changed after you read the plan. Even so, nothing replaces a backup, and the SQL Server tools can take one first.

Azure calls run as you, through a browser sign-in once or through your existing az login, in any tenant you belong to. The SQL tools use your Microsoft account, your Windows sign-in or a SQL login, and every connection is encrypted. A SQL login's password is kept until the app closes, or in your system's secure store (DPAPI on Windows, Keychain on Mac, libsecret on Linux) if you tick Remember. It is never written to a settings file, a project file or a log.

The line is the line in your whole script, not in the batch SQL Server was running, so a message that starts Error at line 11 (208): points at line 11 of the file. Click the error's Line link to see the script at that line; the desktop app marks every line an error came from in red. The number in brackets is SQL Server's error number.

Stop on first error is on, so once Shop_Archive failed no more databases started. Fix the script or the database and run again, or turn Stop on first error off to let every database try. Grey databases changed nothing.

The script may change something and the question could not be asked, because input was redirected, as in a pipeline or a scheduled task. Add --yes to run it without the question, after checking the script yourself.

The command needs to know where to run. Give --server sqlhost with --database Shop, once for each database, or --server sqlhost --all-databases, or --project shops.multirunner.json on its own. A project file and --server together are refused with Give --project, or --server with --database or --all-databases, not both.

The script is kept relative to the project file when it sits beside or under it, so move the script back or edit the script setting. In VS Code the problem also shows in the Problems panel on the line that names the script. The same message comes from a SQL Scheduler step that runs the project.

Turn on the diagnostics log: in a desktop app, Settings, then Write a diagnostics log; in VS Code, the extension's diagnostics setting; for the benchdog command, set the environment variable BENCHDOG_DIAGNOSTICS=1. Each run writes one file to the logs folder in the Benchdog folder (%LOCALAPPDATA%\Benchdog\logs on Windows, ~/Library/Application Support/Benchdog/logs on Mac, ~/.local/share/Benchdog/logs on Linux), and the last ten are kept. The desktop apps have Open logs folder, and VS Code has the Open Diagnostics Logs Folder command.

The log records sign-in requests, Azure calls, engine requests, SQL connections, times and errors. Passwords, connection strings, tokens, secret values and your data are never written, so it is safe to send to support.

That is the crash window, for an error the app did not expect. Copy details puts the error and its details on the clipboard, Email support opens a message to support with them, and Open logs folder shows the crash report, which is written even with the diagnostics log off. If the error happened on a background thread the app has to close, and the window shows when it next starts.

Browser sign-in keeps its tokens in the desktop keyring, and that machine has none unlocked, which is common in WSL. Install and unlock a keyring such as GNOME Keyring or KWallet, or sign in with az login and turn on Use az login in Settings or pass --cli to the benchdog command. Benchdog never falls back to a plain file for tokens.

The SQL Server you connected to uses a certificate your machine does not trust, which is usual for a server on your own network with a self-signed certificate. Pick Trust the server's certificate in the picker, or add --trust-server-certificate on the command line, for servers you know. For a server you do not know, install its certificate chain instead.

In a desktop app, choose Forget saved password from the menu. On the command line, run benchdog sql forget-password --server <server> --sql-login <login>. Either removes it from the system's secure store, which is the only place it was kept.

Write to support@benchdog.dev or use the support form on this site, and a person replies. Say which tool and version you were using (Help, About in a desktop app shows both), what you did and what you saw, and attach the diagnostics log if you have one.