Microsoft SQL Server

AddisDB talks to SQL Server through its own pooled driver — no ODBC layer to install, nothing to configure on the machine. Monitoring reads the dynamic management views, and mock-data inserts handle IDENTITY columns properly.

Who it is for

SQL Server is the backbone of a great deal of enterprise and .NET software. Its query optimizer, tooling and operational maturity are genuinely excellent, and it is often not a choice so much as an environment you have inherited.

Two things it does better than most: the plan cache and statistics infrastructure make it unusually good at diagnosing its own slow queries, and the DMVs expose that state as ordinary tables you can query — which is exactly what the Live Monitor reads.

You will be on it for line-of-business applications, Dynamics or Sitecore-style platforms, and anything built on the Microsoft stack. Azure SQL Database is the same engine as a managed service.

Set up the server

1. Azure SQL: create the database, then under Networking add a firewall rule for your client IP — a new Azure SQL server denies every address until you do.
2. Copy the server name (something like myserver.database.windows.net) and use the SQL admin login you set at creation.
3. On-premises: enable SQL Server Authentication (Mixed Mode) if you plan to use a SQL login rather than Windows auth, and make sure TCP/IP is enabled in SQL Server Configuration Manager.
4. Confirm port 1433 is open through the host firewall. A named instance on a dynamic port needs the SQL Server Browser service, or an explicit static port.
5. Local: the mcr.microsoft.com/mssql/server Docker image runs Developer edition for free.

# A local SQL Server for testing
docker run -e ACCEPT_EULA=Y -e MSSQL_SA_PASSWORD=Str0ng!Passw0rd \
  -p 1433:1433 -d mcr.microsoft.com/mssql/server:2022-latest

-- A login that can read one database and see the monitor
CREATE LOGIN addisdb WITH PASSWORD = 'Str0ng!Passw0rd';
USE app;
CREATE USER addisdb FOR LOGIN addisdb;
ALTER ROLE db_datareader ADD MEMBER addisdb;
GRANT VIEW SERVER STATE TO addisdb;

Connect from AddisDB

1. New Connection → SQL Server. Port prefills to 1433, database to master and username to sa.
2. Enter the server name as the Host and set Database to the database you actually want — master is only a starting point.
3. Azure SQL requires encryption: set SSL mode to require.
4. Test, then Save.

Azure SQL logins are often written user@servername. Paste the whole thing into Username; the suffix is part of the login, not a typo.

T-SQL that behaves like T-SQL

AddisDB sends your editor text to SQL Server as a batch rather than splitting it on semicolons, so DECLARE, BEGIN…END, IF and a multi-statement script all execute as one unit the way they would in Management Studio.

T-SQL also has no LIMIT clause, so previews are capped on decode instead of by rewriting your query. Your TOP or OFFSET…FETCH clause stays exactly as you wrote it.

What AddisDB gives you

• Schema introspection across schemas, with the foreign-key diagram and saved views.
• Live Monitor built on the DMVs — running requests, blocking sessions, waits and connection counts, plus the flight recorder for replaying an incident.
• Mock data that respects IDENTITY columns, tracked by primary key and removable in one click.
• Automatic row capping — SQL Server has no LIMIT, so AddisDB caps previews without rewriting your T-SQL.
• AI querying grounded in your real schema, and one-click repair for failing statements.
• ⌘K search, the Chart view, notebooks, and the full safety model.

The monitor needs VIEW SERVER STATE. Without it, SQL Server returns only your own session, so the panel looks quiet on a busy server rather than reporting a permission error.