SSMS itself never asks you to type a connection string. It uses a Connect dialog with separate fields for server name, authentication, and encryption — but every one of those fields maps directly onto the ADO.NET connection string your actual application uses, and that mapping is the part most explanations skip.
This matters because the question almost always comes from someone building an app, not someone using SSMS to browse a database by hand. They connected fine in SSMS, and now they need the equivalent string for a SqlConnection in code, and the dialog does not hand it to them in an obvious way.
Table of contents
- Why SSMS doesn’t have a connection string box
- Mapping the Connect dialog fields to a connection string
- Example connection strings
- Common connection errors and what field they map to
- The SSMS 20+ default encryption change
- What this means if you don’t run SQL Server
- Pooling parameters that belong in the string too
- How this fits the rest of the stack
- FAQ
Why SSMS doesn’t have a connection string box
SSMS is a client tool built around discrete fields because that is friendlier for a human filling in a form than a raw delimited string. What most people do not realize is that SSMS builds a connection string internally from those fields every time you connect — you just do not see it by default.
You can get it: right-click an active connection in Object Explorer, choose Properties, then Advanced, and there is a “Copy Full Connection String to Clipboard” option. It is one of the more useful hidden features in SSMS, and it is the fastest way to confirm exactly what SSMS sent, rather than guessing at the mapping.
Mapping the Connect dialog fields to a connection string
Each field in the Connect to Server dialog corresponds to a specific key in the ADO.NET connection string format.
- Server name -> Server (or Data Source) — a plain hostname or IP
- Named instance -> appended to the server with a backslash: Server=myhost\SQLEXPRESS
- Non-default port -> appended with a comma instead: Server=myhost,1433
- Windows Authentication -> Integrated Security=True, no user or password in the string
- SQL Server Authentication -> User Id=… and Password=… added explicitly
- Encrypt Connection checkbox -> Encrypt=True (or Mandatory/Strict on newer client versions)
- Trust Server Certificate checkbox -> TrustServerCertificate=True or False
The last two fields are the ones that changed behavior most recently and cause the most confusion, covered in its own section below.
Example connection strings
Three shapes cover almost every real case: SQL authentication against a named server, Windows authentication against a named instance, and Azure SQL Database.
; SQL Server Authentication, non-default port
Server=myserver,1433;Database=mydb;User Id=appuser;Password=REPLACE_ME;Encrypt=True;TrustServerCertificate=False;
; Windows Authentication, named instance
Server=myserver\SQLEXPRESS;Database=mydb;Integrated Security=True;Encrypt=True;TrustServerCertificate=True;
; Azure SQL Database
Server=tcp:myserver.database.windows.net,1433;Database=mydb;User Id=appuser;Password=REPLACE_ME;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;Azure SQL Database always requires Encrypt=True with a properly trusted certificate — it is a managed public endpoint, and Microsoft’s own certificate chain is already trusted, so TrustServerCertificate should stay False there rather than being flipped to bypass an error.
Common connection errors and what field they map to
Three error shapes account for most SSMS and application connection failures, and each one points at a specific field.
- Error 26, “Error Locating Server/Instance Specified” — the server name or named instance is wrong, or the SQL Server Browser service is not running so the instance name cannot resolve to a port
- Error 40, “Could not open a connection to SQL Server” — the port is wrong, a firewall is blocking it, or TCP/IP is disabled in SQL Server Configuration Manager
- “The certificate chain was issued by an authority that is not trusted” — Encrypt is on and TrustServerCertificate is off against a self-signed or internal CA certificate the client does not recognize
The certificate error is the one people reach for TrustServerCertificate=True to silence, which works but disables certificate validation entirely. That is a reasonable trade for a local dev database and a real risk for anything reachable over the internet.
The SSMS 20+ default encryption change
Versions of SSMS from 20 onward default the Encrypt setting to Mandatory rather than the older Optional/off default, which means a connection that worked for years against a server with no valid certificate suddenly fails after an SSMS upgrade with no change to the server at all.
If a connection that used to work now throws a certificate error immediately after upgrading SSMS, this default change is almost always the cause. The fix is either to properly configure a trusted certificate on the SQL Server instance, or to explicitly set Trust Server Certificate to Yes in the Connect dialog’s Encryption tab for that one connection — not to assume the server itself changed.
What this means if you don’t run SQL Server
RunxBuild’s managed databases are MySQL and Postgres — SQL Server is not something we host directly, and it would be dishonest to pretend otherwise. If your application talks to a SQL Server instance running somewhere else (Azure SQL, an on-prem box, another provider), the useful move is to host the application itself here and keep this connection string out of the codebase entirely.
Set it as an environment variable on the deployed service instead of hardcoding it, the same way you would for any other secret. Node services on RunxBuild and the equivalent Python and Docker paths all support environment variables at deploy time, which means the connection string — and the password inside it — never touches source control.
Pooling parameters that belong in the string too
Once the string works, the keys people forget are the pooling ones, and a missing pool setting is a slower, more confusing failure than a missing password — the app just gets sluggish under load instead of refusing to start. Pooling=True is the ADO.NET default, but Min Pool Size and Max Pool Size are worth setting explicitly rather than trusting the defaults on anything beyond a small internal tool.
Server=myserver,1433;Database=mydb;User Id=appuser;Password=REPLACE_ME;Encrypt=True;TrustServerCertificate=False;Min Pool Size=5;Max Pool Size=100;Connection Timeout=30;A Max Pool Size set higher than the number of connections your SQL Server instance or Azure SQL tier actually allows is a common cause of intermittent “timeout expired” errors under load that have nothing to do with the query itself — the app is waiting for a pooled connection that the server has already refused to hand out.
Application Name= is a small addition worth making a habit: it tags every connection from that service in sys.dm_exec_sessions on the server side, which turns “something is holding 40 connections open” from a guessing game into a one-line query against the DMV. It costs nothing to add and pays for itself the first time a connection leak needs tracing back to a specific service, especially once more than one service shares the same database and the connection count climbs for no obvious reason.
How this fits the rest of the stack
If the database side of this project can move to Postgres or MySQL rather than staying on SQL Server, that is worth modeling honestly rather than assumed: managed instances on either engine come with connection limits, backups, and private networking already handled, and the RunxBuild dashboard hands you the resulting connection string directly instead of making you reconstruct it field by field. The RunxBuild hosting calculator shows what that looks like next to the web service that holds the connection string, so the comparison is a real number instead of a guess.
Useful related references:
- PostgreSQL Connection String: libpq URI, Keyword/Value, and Code Examples
- SQL Server to PostgreSQL Migration: The Type Map, the T-SQL That Breaks, and a Cutover Plan That Does Not Lose Rows
- SQL Managed Instance: The PaaS Database, the Cost, the Migration Story, and When to Use One
- Database network security on RunxBuild
FAQ
Where do I find my SSMS connection string?
SSMS does not display it by default. Right-click the active connection in Object Explorer, choose Properties, then Advanced, and use “Copy Full Connection String to Clipboard” to get the exact string SSMS built from your dialog settings.
What does TrustServerCertificate do?
It controls whether the client validates the server’s TLS certificate against a trusted authority. Set to False (the safer default), an untrusted or self-signed certificate causes the connection to fail. Set to True, the connection encrypts traffic but skips certificate validation, which is acceptable for local development and risky for anything reachable over the public internet.
Why do I get SQL Server error 26?
Error 26, “Error Locating Server/Instance Specified”, almost always means the server name or named instance is typed incorrectly, or the SQL Server Browser service is stopped so the instance name cannot be resolved to the port it is actually listening on.
Why do I get SQL Server error 40?
Error 40 means the client reached the machine but could not open a connection to the SQL Server instance itself — usually a firewall blocking the port, TCP/IP disabled in SQL Server Configuration Manager, or the wrong port specified for a non-default instance.
Can I paste a connection string directly into the SSMS Connect dialog?
Not as a single field. SSMS 21 introduced a “Modern connection dialog” option under Tools, Options, Environment, Connection Dialog that streamlines this, but the classic dialog still expects the individual fields (server, authentication, database) rather than one pasted string.