Benchdog SQL Search

Run benchdog sql search Loyalty --server sqlhost --all-databases --windows to search every database on a server you can see, or give --database Shop --database Archive for some of them. Add --sql-login sa for a server that only allows SQL logins, and --trust-server-certificate for a server on your own network with a self-signed certificate.

Each database lists its matches one a line, such as dbo.GetPoints (procedure) line 3: SELECT Points, LoyaltyLevel, then its notes, and the last line sums up, such as 14 matches in 3 of 3 databases. The exit code is 1 when a database could not be searched, so a script can tell.

Look in chooses names, column names and code, and Objects chooses the kinds of object: tables, views, procedures, functions, triggers, synonyms, sequences and types. Each choice is kept as it changes.

On the command line, --no-names, --no-columns and --no-code leave a place out, and --kind procedure keeps to one kind; give it more than once for several. So benchdog sql search Loyalty --server sqlhost --all-databases --kind procedure --no-names --windows looks only in the code of procedures.

Match case makes upper and lower case matter; otherwise case is ignored. Whole word finds the text only when it stands alone, so @Order is found but not @OrderId. With Wildcards, * stands for any run of characters on one line and ? for any one character, so Cust*Id finds CustomerId. A search with a dot, such as sales.Cust, looks at two-part names, and a search never matches across lines.

On the command line these are --match-case, --whole-word and --wildcards, as in benchdog sql search "Cust*Id" --server sqlhost --database Shop --wildcards --whole-word --windows.

The list can hold databases on many servers, each with its own sign-in. Add databases from a second server with the + button, or right-click a server in VS Code and choose Add Databases on This Server to add more from one already there. In VS Code, tick a server to search all of its databases; in the desktop app, the tick at the top ticks or clears them all. Four databases are searched at a time, and the results come back in the order you gave them.

On the command line, one command searches one server, so for several servers save a project file and run benchdog sql search --project shops.sqlsearch.json.

Click a match. In VS Code the object's script opens read only in an editor tab at its line, with every line that holds the text highlighted; in the desktop app the script shows beside the results, coloured like an editor, and Copy script, or Ctrl+Shift+C, puts it on the clipboard.

Views, procedures, functions and triggers show their code as SQL Server keeps it, so the line numbers match the search. Tables, synonyms, sequences and types have no code in SQL Server, so they get a CREATE script made from the database as it is now.

Choose Save as Project File on the Databases view's menu in VS Code, or File, Save as project, Ctrl+Shift+S, in the desktop app. On the command line, add --save-project shops.sqlsearch.json to a search to write the file first. The file keeps each database with its server, name and sign-in, and the search with its text, kinds, places and match options, and it never holds a password.

Open Project File in VS Code, or File, Open project in the desktop app, adds the file's databases, ticks only them and fills in its search, so Search runs it. benchdog sql search --project shops.sqlsearch.json runs it from the command line, and any text or option you add on the command line adds to the project's search. Comments and trailing commas are allowed in the file.

A search stops at 2,000 matches and says so, so a short list is never mistaken for a full one. On the command line, --max 5000 raises the limit, and a project file can set maxMatches. In VS Code and the desktop app, narrow the search instead: tick fewer databases, turn on Whole word, or search for something more exact.

Only each database's catalog, in one round trip: the names of its tables, views, procedures, functions, triggers, synonyms, sequences and types, the column names of tables and views, and the code SQL Server keeps for views, procedures, functions and triggers. No row of table data is ever read, and nothing in a database is changed. Connections are always encrypted, and every database is reached as you.

It needs to connect to the database and see its objects. Searching code needs VIEW DEFINITION on the objects; without it, names and column names are still searched, and an amber note under the database says which objects' code could not be read. Code created WITH ENCRYPTION cannot be read by anyone, and the note names those objects too, so you always know what was left out.

Tables, views, stored procedures, functions, triggers, synonyms, sequences and user-defined types, in as many databases as you tick, on one server or many. It searches the objects inside each database, not server objects such as logins or Agent jobs, and it reads SQL Server 2017 or later and Azure SQL.

It finds text; it never replaces or changes it. A search never matches across lines, so a name split over two lines of code is not found. Encrypted code cannot be searched, and the notes under a database say which objects were left out. It does not search table data, so a value in a row is not a match.

SQL Search reads the live catalogs, so what you find is what is deployed right now, with no files on disk to keep up to date or to clean up. It searches four databases at a time across every server in your list, groups the matches by database and object, and opens the code at the line, with the line numbers SQL Server itself uses.

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 database could not be opened, and the reason is under the tag, or on the command line in a line such as Shop_Old on sqlhost: could not be searched. followed by the reason. Every other database is still searched. Check the database's name and the server it is on, how it signs in, and for a server on your own network, that Trust the server's certificate is ticked. The command line exits with code 1 when any database could not be searched.

The notes say which code was left out: 2 objects are encrypted, so their code was not searched: dbo.GetPoints, dbo.SetPoints. or The code of 2 objects can not be read, so it was not searched: dbo.Rebuild, dbo.Archive. Reading code needs VIEW DEFINITION. Encrypted code cannot be read by anyone. For the rest, ask for VIEW DEFINITION on those objects, or on the database, and the names and columns are searched either way.

The last line reads 2,000 matches in 3 of 3 databases. There were more; search for something more exact to see them. A search stops at 2,000 matches so the list stays useful. Search for a longer or more exact text, turn on Whole word or Match case, tick fewer databases or kinds, or on the command line raise the limit with --max 5000.

Type what to search for. means the text was empty. Search for more than wildcards, such as Cust* or *Order?. means the text was only * or ? with Wildcards on, which would match everything. Search for text on one line. A search never matches across lines. means the text held a line break. The search took too long on one line. Search for something more exact, with fewer wildcards. means one line took over two seconds to match, which a pattern of many wildcards can cause.

The code of dbo.GetPoints can not be read: it is not in the database, it is encrypted, or reading it needs VIEW DEFINITION. means SQL Server returned no code for the object, so ask for VIEW DEFINITION or check that it still exists. dbo.GetPoints is not in the database any more. Search again. means the object was dropped after the search ran, so the results are out of date.

VS Code shows every problem in the Problems panel on its line, and the command line names the file, line and column. The messages say what to fix, such as give the "databases" to search, each with its "server" and "database"., Shop on sqlhost is in the list twice., signIn for Archive must be entra, windows or sql., Archive signs in with sql, so it needs a "user". The password is never kept in a project file., names, columns and code are all false, so there is nowhere to search. Leave one out, or set it to true., maxMatches must be 1 or more. and job in kinds is not a kind of object. Use table, view, procedure, function, trigger, synonym, sequence or type.

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.