Query SQL Database from Portal

You’ve built your database, configured your server, and secured your connection strings—but now you need to actually see the data. The Azure portal’s query editor is the fastest way to inspect, test, and validate your SQL database without installing any client tools. In this lesson, you’ll learn how to query SQL database from the portal, run ad-hoc queries, and troubleshoot common issues—all from your browser.

The problem this lesson solves

When you’re developing against Azure SQL Database, you often need to quickly verify data, test a new query, or debug a connection issue. Downloading and installing SQL Server Management Studio (SSMS) or Azure Data Studio is overkill for a quick check, and it adds setup friction—especially when you’re working on a cloud-only machine or a Chromebook. The Azure portal’s built-in query editor gives you a zero-install, browser-based way to query SQL database from the portal. But it has quirks (like firewall rules and authentication quirks) that can trip you up if you don’t understand how it works. This lesson eliminates that frustration.

By the end, you’ll be able to:

• Navigate to the query editor in the Azure portal.
• Run and save ad-hoc queries directly against your Azure SQL Database.
• Handle authentication, firewall, and syntax errors like a pro.

That means faster debugging, smoother demos, and more time building—not wrestling with tooling.

Core concept / mental model

Think of the Azure portal’s query editor as a lightweight version of SSMS—but it lives in your browser and is always connected to your database. It’s a web-based SQL client that executes T-SQL commands against your Azure SQL Database and returns results as a grid, just like you’d see in a desktop tool.

What it is (and isn’t):

When does it shine? It’s perfect for:

• Testing read-only queries against production data.
• Validating that your schema changes look right.
• Sharing a quick query with a teammate (just copy the URL).
• Running a sanity check on a new deployment.

The mental model: You point your browser at the portal, open the query editor, authenticate, write SQL, and get results—no client-server setup, no VPN needed (except for firewall rules).

How it works step by step

The portal query editor is built on top of the Azure SQL Database service—it’s essentially a thin client that connects to your database over the internet. Here’s the flow:

1. Navigate to your database resource in the Azure portal (e.g., my-database).
2. Open the query editor from the left-hand menu (under Query editor or Data tools).
3. Authenticate using Azure Active Directory (recommended) or a SQL login.
4. Allow portal IP address for the first time (it adjusts the server firewall automatically).
5. Write and run your T-SQL query in the editor pane.
6. View results in the grid below (or as a chart).
7. Save or export results if needed.

Under the hood: The editor uses the same connection string path as any client, but with an extra hop through the Azure portal’s API. That means your server’s firewall must allow the request—which is why you’re prompted to whitelist the portal IP when you first connect.

Authentication options:

• Azure AD (recommended): Uses your Azure credentials—no password stored in code, supports MFA.
• SQL authentication: Uses the server admin login you set up when you created the server.
• Not supported: Windows integrated auth, because it’s a browser environment.

Hands-on walkthrough

Let’s query SQL database from the portal with a real example. We’ll use a sample database—if you don’t have one, create a free Azure SQL Database with the AdventureWorks sample dataset.

Step 1: Open the query editor

1. Go to the Azure portal.
2. Navigate to SQL databases → select your database.
3. In the left menu, under Data tools, click Query editor (preview).
4. If prompted, sign in with your Azure AD account (select “Sign in with Azure Active Directory”).

Step 2: Allow the portal IP

If this is your first connection, you’ll see a prompt like:

“The server firewall has not been configured to allow the portal’s IP address. Click ‘Allow’ to add it.”

Click Allow — this adds your current IP to the server firewall rules automatically. (You may need server-level permissions, but your own databases are usually fine.)

Step 3: Run your first query

Type the following T-SQL query into the editor:

-- Read top 10 rows from SalesLT.Customer
SELECT TOP 10
    CustomerID,
    FirstName,
    LastName,
    EmailAddress
FROM SalesLT.Customer
ORDER BY CustomerID;

Click Run. You should see results in the grid below, like this (sample output):

CustomerID | FirstName | LastName | EmailAddress
-----------|-----------|----------|----------------------
1          | Orlando   | Gee      | orlando0@adventure-works.com
2          | Keith     | Harris   | keith0@adventure-works.com
... (8 more rows)

Step 4: Test a JOIN and aggregation

Now let’s verify relationships—useful for debugging data integrity:

SELECT
    c.CustomerID,
    COUNT(o.SalesOrderID) AS OrderCount
FROM SalesLT.Customer c
LEFT JOIN SalesLT.SalesOrderHeader o
    ON c.CustomerID = o.CustomerID
GROUP BY c.CustomerID
HAVING COUNT(o.SalesOrderID) > 5
ORDER BY OrderCount DESC;

Expected output shows customers with more than 5 orders, sorted by order count descending.

Step 5: Verify schema changes

Check that a new column exists (great after a migration):

SELECT COLUMN_NAME, DATA_TYPE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'Customer' AND COLUMN_NAME = 'EmailAddress';

Output should list EmailAddress with type nvarchar.

Step 6: Save your query (session only)

The portal editor doesn’t persist queries across sessions—they’re lost when you close the browser tab. To keep your work, copy the query to a file or a snippet tool. (SSMS or Azure Data Studio saves scripts on disk.)

Compare options / when to choose what

You now have several ways to query Azure SQL. Here’s a quick comparison:

When to use the portal query editor:

• You’re on a machine without database tools.
• You need to verify a query during a demo or live debugging.
• You’re mentoring someone and want to share a runnable query link.

When to avoid it:

• You’re building an application that queries the DB—that belongs in your code.
• You need to run large batch jobs—use a script with proper error handling.
• You need to edit table data directly—the portal editor is read-only for data modification (you can run INSERT/UPDATE, but it’s not a grid editor).

Troubleshooting & edge cases

“The server firewall is blocking your IP”

Symptom: Error Cannot open server 'xxx' requested by the login. Client with IP address 'yyy' is not allowed to access the server.

Fix: Go to your server resource → Networking → add your IP to the firewall rules. The portal editor usually does this for you, but if you have network restrictions or are on a VPN, you may need to add the VPN’s egress IP.

“Login failed for user '…'”

Symptom: When trying to sign in with Azure AD, you get a login failure.

Fix: Ensure you have the SQL DB Contributor role (or at least permission to read/write). Also, verify that Azure AD authentication is enabled on your server (it usually is by default). Try switching to SQL authentication with your server admin login.

Query returns empty results unexpectedly

Symptom: A SELECT returns zero rows, but you expect data.

Fix: Check the database name—the query editor connects to the database you selected, but if you used a cross-database query (like SELECT * FROM otherdb.dbo.table), it may fail if the other database is on a different server. Also, ensure you’re not accidentally filtering with WHERE conditions that exclude all rows.

Timeouts on long-running queries

Symptom: Your query times out after 30 seconds or so.

Fix: The portal editor has a client-side timeout. For heavy queries, use a desktop tool or a stored procedure. Also, optimize with indexes—check the execution plan (available in the editor) to see where the bottleneck is.

Saving queries doesn’t work

Symptom: You can’t find your previously saved queries.

Fix: The portal editor does not persist queries between sessions. Use a local file, or paste your query in a GitHub gist or Azure DevOps wiki. For persistent scripts, use Azure Data Studio or SSMS.

What you learned & what's next

You’ve now mastered the essentials of querying SQL databases from the Azure portal. You can:

• Navigate to the query editor, authenticate, and run ad-hoc T-SQL queries.
• Understand the differences between the portal editor and desktop tools.
• Troubleshoot widespread issues like firewall blocks and login failures.

Where to go next? In the Azure Tutorial track, the next lesson moves beyond ad-hoc queries to programmatic access—imagine using Python with pyodbc to query the same database from your application code. That’s where you’ll apply these skills in a real production scenario, connecting your app securely using managed identities instead of hard-coded credentials. The foundation you’ve built here (understanding schemas, running queries, checking results) will directly transfer to writing efficient data-access code.

Ready to jump into the next lesson? Head over to the next module in the track.