Every developer who has ever fixed data by hand knows the pause. You run a SELECT, eyeball the rows, start writing an UPDATE, and then hover over the WHERE clause one more time before pressing run — because a forgotten predicate turns "fix one row" into "rewrite the whole table." That single moment of dread is where most careless data corruption comes from.

Version 1.37.0 of the MSSQL extension for VS Code, released on November 18, 2025, goes after that pause from two directions at once. It made GitHub Copilot's integration generally available — "GitHub Copilot integration is now GA, bringing AI-powered development directly into your SQL workflow" — and in the same release notes it shipped Edit Data as a public preview. Both are marketed as ways to change table data without hand-writing DML. Under the surface they are different tools with different trust models, and the useful thing is knowing which one you are actually holding.

Two ways to change a row

These features are easy to blur together because they arrived in the same version and solve the same annoyance. They are not the same mechanism.

Edit Data is a grid. It is not AI. Agent mode is Copilot driving the extension's tools with your approval. One lets you skip SQL entirely; the other writes the SQL for you and runs it. The distinction decides how you verify the change before it lands.

The grid path: Edit Data

Edit Data is a preview feature, so it lives behind the experimental flag. Open Settings, search for "Enable Experimental Features," check the box, and reload. Then right-click (or double-click) a table in Object Explorer and pick Edit Data (Preview).

What you get is a spreadsheet-style view of the table with a few deliberate constraints:

Inline cell editing with real-time validation and error handling.
Insert or remove rows without writing any SQL.
Pagination so a wide table doesn't try to render in one shot.
A pending-changes model — nothing is committed until you click Save Changes.

The feature that makes this trustworthy rather than reckless is the Show Script pane. As you edit cells and add rows, it renders the read-only DML that reflects your pending changes in real time. You are not guessing what will run; you are reading the exact UPDATE / INSERT / DELETE statements before you commit them. That is the whole value proposition: a visual editor that never hides the SQL it is about to execute.

The AI path: agent mode

Agent mode is where the "AI" in "editing SQL data with AI" actually lives. It picks up the MSSQL extension's tools automatically — no @mssql mention required — and lets Copilot orchestrate them from natural-language prompts. The tools it contributes are concrete and enumerable: connect, disconnect, change_database, list_servers, list_databases, show_schema, list_tables, list_views, list_functions, and, the one that changes data, run_query.

You can call a tool explicitly with a chat variable like #mssql_connect, or just describe what you want:

Connect to my LocalDev profile, set AdventureWorks as the active database,
then mark every order in SalesLT.SalesOrderHeader placed before 2011
as archived.

Copilot selects the tools, connects using the same credentials the extension already holds, and proposes a query. Behind that last step, run_query would generate something like:

UPDATE SalesLT.SalesOrderHeader
SET Status = 'Archived'
WHERE OrderDate < '2011-01-01';

Here is the part that matters most, and the reason this is defensible for real databases: every tool call requires your approval before it executes. When Copilot picks a tool, it shows a confirmation dialog with the action details and three choices — Allow in this session, Allow in this workspace, or Always allow. Nothing touches your data until you say yes. That approval gate is the difference between "the AI edited my data" and "the AI proposed DML that I read and approved."

The trust primitive is different for each

Both tools skip the part where you type DML by hand. Both also give you a way to see the DML before it runs — and that is the point you should build a habit around.

The safe move is identical in both tools: read the DML before you commit to it. The grid shows you the script pane; agent mode shows you the query in an approval dialog. Neither one asks you to trust a black box — so don't skip the part where you check.

For the grid, the trust primitive is the Script pane. For agent mode, it is the approval dialog and the query text printed inside it. Treat the approval prompt like a code review, not a speed bump. The tempting button — Always allow on run_query — removes exactly the check you want on any statement that mutates data.

Which one to reach for

Use the grid when the target is a known table, the change is a handful of cells, and you can see the rows you're touching. The pending-changes model makes it a batch-review-commit loop, which is exactly right for surgical fixes.

Use agent mode when the change spans many rows or tables, or when you can't yet express it as clean SQL — "add createdAt and updatedAt columns to every table in the Sales schema that doesn't already have them." That is a multi-step job an agent handles well, and the same session also does inline completions across ORMs (Prisma, Sequelize, SQLAlchemy, Entity Framework) and schema exploration. But remember what it is: an agent can misread intent, and a generated UPDATE with a too-broad WHERE is still a too-broad WHERE. The approval dialog is your last line of defense, not a formality.

The takeaway

Turn on the Show Script pane in Edit Data and refuse to click Save Changes until you've read the statement it generated. In agent mode, keep run_query on Allow in this session and never promote it to Always allow — read the query in every approval prompt the way you'd read a diff. The extension now gives you two ways to avoid hand-writing DML. More importantly, it gives you two ways to see the DML before it executes. The engineers who stay out of trouble will use the second half of that gift every single time.

Sources: