Continuing from Part 1, where we set up a SQL Database in Microsoft Fabric, loaded the AdventureWorksLT sample data, and explored the SQL Analytics Endpoint. If you missed it, go check that out first link below FYR
One SQL Anywhere—Designing Scalable Data Solutions... - Microsoft Fabric Community
So in Part 1 we got the database up and running, loaded some sample data, and poked around the SQL Analytics Endpoint. Pretty straightforward stuff if you've worked with Azure SQL before.
Part 2 is where it gets interesting.
I want to talk about Copilot inside the SQL query editor. I'll be honest—when I first saw "Copilot" mentioned in Fabric, my initial reaction was okay, another AI button that generates generic SQL and gets the table names wrong. But this one is different. It actually knows your schema. It's not just an LLM bolted on top — it's context-aware, and that changes things quite a bit.
Let me walk you through five things I tried and what actually happened.
1. Writing queries with inline suggestions
This is the simplest one. You open a query window, type a comment describing what you want, and Copilot suggests the T-SQL inline—right in the editor, like a ghost autocomplete.
Open a new query window and type this:
sql-- Create a query to get the product that is selling the most
Press Enter or Space. You'll see a small loading spinner at the bottom of the editor for a second, and then the suggested query appears—greyed out, like a tab-completion suggestion. Press Tab to accept it, then run it.
What I liked here: it didn't just write a generic SELECT TOP 1 query. It joined the right tables (SalesOrderDetail and Product), grouped by the right columns, and ordered by quantity sold. It figured that out from the schema without me telling it anything beyond the comment.
That's the part that actually impressed me.
2. Fixing broken queries—this one saves real time
Alright, this is the one I'll probably use the most in real work.
Open a new query window and paste this in:
SQL : SELECT c.CustomerID, c.FirstName, c.LastName,
COUNT(so.SalesOrderID) AS TotalPurchases,
SUM(so.SubTotal) AS TotalSpent,
AVG(so.SubTotal) AS AverageOrderValue,
MAX(so.OrderDate) AS LastPurchaseDate
FROM SalesLT.Customer AS c
JOIN SalesLT. SalesOrderHeader AS so ON c.CustomerID = so. CustomerID
GROUP BY c.CustomerID, c.FName, c.LName
ORDER BY TotalSpent DESC;
Hit Run. You'll get errors—the GROUP BY is referencing c.FName and c.LName, which don't exist. The actual column names are FirstName and LastName.
Now click "Fix query errors" from the Copilot toolbar.
It corrects the column names, and—this is the part I appreciated—it adds a comment in the query explaining exactly what was wrong and what it changed. So you're not just getting a fixed query; you're getting an explanation alongside it. Run it again, and it works cleanly.
I know this sounds like a small thing. But if you've ever spent 15 minutes hunting a GROUP BY mismatch in an 80-line query, you know exactly why this matters.
The explain feature is underrated
While you're here, try selecting any query and clicking "Explain query." Copilot adds plain English comments line by line explaining what each part does.
This is genuinely useful when you're reviewing someone else's query or when you've inherited a report and you're trying to figure out what it's actually doing before you touch it.
Natural language to SQL—via the Chat Pane
This is a step up from inline suggestions. Instead of writing a comment in the query editor, you open a dedicated Copilot chat panel and just... ask it things.
Click Copilot on the Home tab, then click Get started. You'll see a chat input at the bottom.
Type this:
Write a query that will return the most sold product.
Copilot responds with a T-SQL query and a short explanation of what it's doing. Click Insert to push it straight into your query editor, then run it.
A note from my experience: sometimes Copilot doesn't nail it on the first attempt—especially if the question is a bit ambiguous. Just rephrase and ask again. It's a conversation, not a one-shot prompt.
4. Asking for results directly—no query editor needed
Here's where it shifts from a developer tool to something a bit broader.
In the same Copilot chat pane, instead of asking it to write a query, ask it a business question directly:
What is the most sold product?
Copilot doesn't give you SQL this time. It queries the database itself and returns the answer right inside the chat—as a table or a plain text answer.
Think about what this means for non-technical users. Someone wants a quick data check during a meeting. They don't need to open a query editor or wait for a report to refresh. They just ask. And they get an answer.I'm not saying this replaces proper reporting—it doesn't. But for quick spot checks and ad hoc questions, it's genuinely useful.
5. Write with approval—Copilot creates database objects
This is the most powerful task in this post and also the one to be most careful with.
In the Copilot chat pane, switch the mode to Read and write (with approval) from the dropdown. Then type:
Create a view in the SalesLT schema using this query and execute it.
Copilot generates the CREATE VIEW statement and shows it to you before doing anything. You review it, then click Run (or Approve) to confirm. Copilot executes it, and after a few seconds it confirms the view has been created.
Go to the Explorer pane on the left, expand SalesLT, and open the Views folder—your new view is right there.
The approval step is not just a safety feature. It's a governance feature. In any production or near-production environment, you don't want AI autonomously creating or altering schema. The fact that Fabric built the approval step in by default is the right call.
Honest take
I went into this expecting a gimmick. I came out actually changing how I work.
The inline suggestions speed up the initial drafting. The error fixing saves the debugging grind. The natural language chat opens this up to people who don't write T-SQL daily. And the write-with-approval capability means you can use it for actual schema work, not just querying.
The key thing that makes it work—and what separates it from generic AI tools—is that it's schema-aware. It knows your tables, your column names, your relationships. It's not guessing. That's what makes the suggestions actually usable rather than just directionally correct.
If you're already working inside Microsoft Fabric, there's no reason not to have this open alongside your query editor.
What's next
Part 3 is going to be a good one—we're getting into RAG Architecture Simulation using SQL Database in Microsoft Fabric. If you've been hearing a lot about Retrieval-Augmented Generation but wondered how it fits into a Fabric SQL context, that's exactly what we'll break down. Stay tuned.
Happy reading!
on:
One SQL Anywhere – Part 2: Copilot in SQL Database...
on:
One SQL Anywhere - Designing Scalable Data Solutio...
rajendraongole1
on:
Mirroring SharePoint Lists in Microsoft Fabric: Bu...
on:
Open Mirroring in Microsoft Fabric: A Step-by-Step...
on:
Automated Deployment of MSFT Fabric Database via A...