[FEATURE] JIT access to Azure SQL DB needs database name to test the connection

[benjamin-szczur]

Which component(s) does this affect?

• Desktop App
• CLI Tool
• SSMS Extension
• Plan Analysis Rules
• Documentation

Problem Statement

Hi @erikdarlingdata.

The Connect to Server dialog only allows me to enter the server name. After pressing the Test Connection button, the allowed databases will be shown in the Database lookup.

However, I work as a technical consultant, and for database analysis, we must request JIT access to the Azure SQL DB that our customers use. The aforementioned dialog fails in my business case when I enter either the server name or the complete instance name (server name\database name).

I have therefore cloned your repository and modified this dialog to allow entering the complete instance name, including the database, after which the connection is valid.

If you are interested in this change, I can provide it to you.
Feel free to respond to this issue.

Thank you very much for providing this great tool, and have a nice weekend!

BR Benjamin

Proposed Solution

Modify the Connect to Server dialog so that the full instance name, including the database name, can be entered all at once in the Server name text box. This will also (pre-)select the correct database instead of the "master" DB in the Database lookup.

Use Case

Instead of using SSMS or the stored procedures provided by Eric, such as the sp_QuickieStore, access the Query Store via Performance Studio.

Alternatives Considered

No response

[erikdarlingdata]

Hi @benjamin-szczur — thanks for the kind words and the well-described request!

I've implemented this in #359, now merged into dev. Rather than parsing the database out of the server-name box (the server name\database name form), I added a dedicated optional "Initial database" field to the Connect dialog. The reason: \ is named-instance syntax for on-prem SQL Server (SERVER\INSTANCE), so overloading the server box would collide with that case — a separate field keeps both scenarios unambiguous. This also matches how the sibling PerformanceMonitor app already handles Azure SQL DB connections.

How it works:

• Leave the field empty → unchanged behavior (connects to master, lists databases, you pick one).
• Enter a database name → Test Connection connects straight to that database instead of master, and pre-selects it in the Database dropdown — so it works even when your JIT login can't open master.

I don't have an Azure SQL DB with JIT access to test the real path against, so I'd be grateful if you could confirm it works for your business case. It'll be in the next nightly build — no need to build from source; just grab that once it's published and try the Azure SQL DB connection. Let me know how it goes!

Thanks again!

[benjamin-szczur]

Hi @erikdarlingdata

Thank you very much for your quick help and solution. I agree that adding a new text box for the database name is the best solution.
I only thought of a quick solution to my issue without adding a new text box to the dialog. However, I did not consider instances' names on on-prem servers. You are absolutely right.

I can confirm that the change works well with my JIT access and individual database name.

One more thing to add:
When I reconnect, the database name is empty. The other data, such as the server and credentials, remain.
Would you like to change this as well?

Thank you again and wish you a nice weekend.

BR Benjamin

[benjamin-szczur]

I close this case as the asked Feature is solved.
However here is a small optimization already mentioned in my last comment:

When I reconnect, the database name is empty. The other data, such as the server and credentials, remain.
Would you like to change this as well?

[erikdarlingdata]

I'm going to re-open it to track that one. It shouldn't be hard. Been a bit busy on other things but will see what I can do here.

[erikdarlingdata]

Hi @benjamin-szczur — good catch, and thanks for following up on this.

It turned out the initial-database field was meant to persist, but there was a bug: when saving a connection to a server you'd already used before, the save path updated everything (server, auth, credentials, encryption) except the database name — so it silently got dropped. Since your Azure server was already in your saved connections, you hit that path every time, which is why the field kept coming back empty. As a bonus, it also meant a saved server's initial database could never be changed.

Fixed in #360, now merged into dev. The Initial database field will now be remembered and pre-filled when you reconnect, just like the server name and credentials.

It'll be in the next nightly build — no need to build from source, just grab that once it's published and confirm the database name sticks across reconnects. I'll leave this open until you've had a chance to verify.

Thanks again for the clear reports!