Connect Microsoft SQL Server to Excel, Sheets and AI

Deployed the way SQL Server actually is

Real instances are rarely the tidy default. The connection details cover the arrangements people genuinely have rather than the one in the documentation.

• Named instances go in the server box as SERVER\SQLEXPRESS or SERVER\PROD. There is no separate field to hunt for and no port to supply unless you moved it.
• Port 1433 is assumed and left out of the connection string entirely; anything else is used as given, so an instance on 1435 needs nothing special.
• One connection addresses one database, and several databases on the same instance are simply several connections — each with its own login and its own permissions if that is how your shop works.
• Encryption is yours to set, along with whether to trust a self-signed certificate.
• Authentication is SQL Server authentication — a login and a password. Windows and Microsoft Entra authentication are not supported, and if your instance is set to Windows-only the connection test says so instead of failing obscurely.

What it does to your instance, precisely

Anyone who looks after a production SQL Server will want to know what a new reader costs them. The short answer is one connection at a time and nothing left behind.

• Connection pooling is off, on purpose. No pool of idle sessions accumulates against your instance between queries, which is the opposite of what most reporting tools do.
• Cancelling actually cancels. When a query is stopped, the cancel is sent to SQL Server so execution ends there — rather than the client walking away and leaving the server working on a result nobody will read.
• Reachability is checked before a login is ever attempted, so a wrong hostname or a closed port fails as a network error instead of arriving as a failed login in your error log — which matters if you have lockout policies.
• Timeouts are explicit: 30 seconds to connect by default, and 35 seconds for a query to start returning. Long results then stream for as long as they need to.

T-SQL types that survive the trip

Getting SQL Server data into a spreadsheet is where precision usually goes quietly missing. These are the cases that have been dealt with deliberately.

• datetimeoffset keeps its instant, normalised to UTC, rather than being flattened to a local wall-clock time that means nothing to the next reader.
• decimal and numeric keep their precision and scale. Beyond what a spreadsheet can hold, the value is handed over as exact text rather than silently rounded — wrong money is worse than inconvenient money.
• money and smallmoney arrive as exact decimals, not floats.
• rowversion and timestamp come across as the eight bytes they actually are, instead of being mistaken for a date, which is the single most common way these columns get misread.
• uniqueidentifier becomes a lowercase GUID string, and sql_variant and hierarchyid become readable text rather than being dropped.

-- The awkward types, handled rather than approximated
SELECT   o.OrderId,
         o.PlacedAt,       -- datetimeoffset  -> UTC instant
         o.RowVersion,     -- rowversion      -> 8 bytes, not a date
         o.Amount,         -- money           -> exact decimal
         o.LedgerBalance   -- decimal(38,10)  -> lossless text
FROM     dbo.Orders AS o
WHERE    o.PlacedAt >= DATEADD(day, -30, SYSUTCDATETIME())
ORDER BY o.PlacedAt DESC;