Reach Azure SQL and Microsoft Fabric without building a connection string

Pointing a JDBC client at Azure SQL is rarely hard for five minutes and then hard for an hour. The connection string wants encrypt, hostNameInCertificate and an authentication mode; the user name may or may not need an @servername suffix; the access token, if you went that way, expires while you are still reading the documentation. And when it fails, the driver says Login failed for user '', which is true and useless.

Version 4.01 replaces the string-assembly step with a dialogue. A new Azure tab asks two questions — what are you connecting to, and how do you want to sign in — and builds the rest itself.

What you are connecting to

The driver entry is Microsoft Azure SQL (Database, Managed Instance, VM), and the target on the Azure tab narrows it further. That choice is not cosmetic — it changes what the rest of the application does:

• Azure SQL Database connects to exactly one database and cannot switch. Set the target and the Server Navigator lists only the database you are actually connected to, instead of offering you a dozen you cannot open. The Database Name field on the same tab picks which one; leave it blank and you get the default database of your sign-in, shown as <default> — the same wording SSMS uses.
• Managed Instance and SQL Server on a VM behave like an ordinary SQL Server, and the navigator behaves accordingly.
• Microsoft Fabric — Warehouse, the SQL analytics endpoint of a Lakehouse, or a Fabric SQL database. See below.

If you already have a connection string, paste it. The JDBC, ADO.NET and ODBC forms are all understood, and the user name and password are lifted out into their own fields rather than left sitting inside the string.

Signing in

The sign-in methods are the ones SQL Server Management Studio offers, for Microsoft SQL Server, Azure SQL and Fabric alike. Your choice is saved with the connection, and the user and password fields switch on and off to match it, so the dialogue never asks for a password a method does not use.

The short one: Microsoft Entra Default

If you work with the Azure CLI anyway, this is the method to pick. Run az login once and connect: no browser window, nothing to type, no token to paste, and no fetching a fresh token by hand every hour. A sign-in you already have from Azure PowerShell, the Azure Developer CLI or Visual Studio Code is accepted just as well. Nothing is stored for it — no password, no token — which also makes it the easiest method to justify in a security review.

Pasting an Entra ID access token by hand remains available, and stays the answer for a locked-down machine with no Azure tooling on it. Existing connections that used Windows authentication keep working and now show that in the list rather than leaving you to infer it.

When Azure says no, you get Azure's reason

This is the part that saves the hour. Where Azure names a cause for refusing the connection, that cause is what you read:

• a firewall rule missing for your current IP address;
• a user name that needs the @servername suffix;
• an access token that has expired;
• outbound port 1433 blocked in your own network.

The dialogue also stops you before the driver does. The Azure tab only opens for a SQL Server, Azure SQL or Fabric driver — or on a connection that already has a target set — and a warning icon on the tab says when a required Entra ID token is still missing. If the driver and the target disagree, or Fabric is set to sign in with a SQL login instead of Entra ID, you are asked, or taken to the Azure tab, before saving or testing.

Microsoft Fabric

Three Fabric endpoints connect: a Warehouse, the SQL analytics endpoint of a Lakehouse, and a Fabric SQL database. Pick the target on the Azure tab and sign in with an Entra ID token, which is what Fabric accepts.

The analytics endpoint serves data that is written through the Lakehouse, not through SQL. So a connection to it is marked read-only, and write statements, grid editing and Data Pumper writes are kept away from it — not as a policy decision, but because the endpoint would refuse them anyway and it is better to say so before you have typed the statement. The same mechanism is available to you by hand on any connection; see environments and read-only.

Encryption, and the driver underneath

SQL Server and Azure SQL connections now use the Microsoft driver's own encryption default — encrypted, with verification of the server certificate. Until 4.00 every SQL Server connection was forced to be unencrypted and a setting in the JDBC URL was overwritten to make sure of it; that is gone. The TLS tab pre-selects Encrypted as soon as an Azure target is chosen, unless you have already set it yourself, and for a server with a self-signed certificate the Trust the server certificate switch sits next to it. Details on secure connections.

Underneath is the Microsoft SQL Server JDBC driver 13.4.0, which is also the driver behind the plain SQL Server entry, with the matching helper library for Windows integrated authentication. Nothing to install: it ships inside the application, like the rest. What else is reachable from the same window is on Beyond IRIS.

Next step

If you have an Azure SQL Database and the Azure CLI on your machine, this is a two-minute test: download SQL DATA LENS, create a connection with the Azure SQL driver, pick Microsoft Entra Default, and see whether it connects without you typing a password.