For years we’ve been treating every one of our Microsoft SQL drivers as a distinct entity. We’ve heard your feedback that we need to re-examine that approach. A team running applications written in multiple languages against one database should not have to juggle multiple connection strings.
We are fixing that.
What changed
We added keyword aliases to SqlClient, JDBC, ODBC, OLE DB, and go-mssqldb, so the same spelling works across all of them.
All five now accept
- Server
- Database
- UID
- App
- Encrypt
- TrustServerCertificate
- ApplicationIntent
- MultiSubnetFailover
- FailoverPartner
We added also added the following aliases:
| Driver | Now accepts | Already worked as |
|---|---|---|
| SqlClient |
ConnectTimeout FailoverPartner PacketSize WorkstationID columnEncryption |
Connect Timeout Failover Partner Packet Size Workstation ID / WSID Column Encryption Setting |
| JDBC |
uid trusted_connection app connectTimeout columnEncryption quotedId |
user integratedSecurity applicationName loginTimeout columnEncryptionSetting quotedIdentifier |
| ODBC |
ConnectTimeout MultipleActiveResultSets FailoverPartner WorkstationID |
no keyword MARS_Connection Failover_Partner WSID |
| OLE DB |
ConnectTimeout MultipleActiveResultSets WorkstationID |
Timeout MarsConn WSID |
| go-mssqldb |
Connect Timeout Failover Partner Application Intent Trust Server Certificate Multi Subnet Failover Host Name In Certificate Server SPN WSID App |
connection timeout failoverpartner applicationintent trustservercertificate multisubnetfailover hostnameincertificate serverspn workstation no keyword |
Nothing is deprecated. Connect Timeout still works in SqlClient, loginTimeout still works in JDBC, WSID still works in ODBC and OLE DB, MarsConn and Timeout still work in OLE DB. No public APIs changed. Move one app to the shared spellings and leave the rest alone.
One string, four languages
One string, assigned once:
Server=<server>;Database=AdventureWorksLT;UID=<user>;PWD=<password>;Encrypt=no;TrustServerCertificate=yes
We pass it unchanged to four clients. All four return the same five rows from SalesLT.Product.
C# on Microsoft.Data.SqlClient. Takes it as-is.
Go on go-mssqldb. Takes it as-is.
Python on mssql-python. Takes it as-is.
C++ on Microsoft ODBC Driver 18. We still use the same string, just with the driver name appended:
;Driver={ODBC Driver 18 for SQL Server}
Will things ever be perfect? No. Some drivers have specific requirements, like the ODBC specification that requires a driver name, like we just saw. That said, remembering to add one tag sure beats having to start over from scratch.
PHP and Django
PHP connects through the ODBC driver, so it picks up the ODBC keywords.
mssql-django runs on pyodbc by default. It can run on mssql-python per connection with OPTIONS = {“python_driver”: “mssql_python”}. Either way it takes the server and database through Django settings and passes the rest through extra_params. On the mssql-python path it drops DRIVER, DSN, and SERVERNAME, because mssql-python bundles its own driver and rejects them. mssql-python also accepts spellings the ODBC driver does not, including Packet Size with a space and addr for the server, and normalizes them before connecting.
This is just the first step
You told us that when we say a keyword is supported it should mean the same thing in every language we ship. We aren’t there yet. This is the first piece.
A big one on our list is Microsoft Entra authentication, although it is more difficult. The drivers rely on per-language frameworks that we do not own. Each has different levels of support for Microsoft Entra authentication methods.
Where to get the new keywords
| Driver | Language | Available in |
|---|---|---|
| Microsoft.Data.SqlClient | C# | 7.1.0 |
| go-mssqldb | Go | v1.11.2 |
| mssql-python | Python | 1.15.0 |
| Microsoft ODBC Driver 18 | C++ | 18.7.1.1 |
| JDBC | Java | 13.6.0 |
| OLEDB | C++ | Coming in October |
If a keyword you expect is still missing in a driver you use, open an issue on that driver’s repo and tell us which one. We want to know what your priorities are.