Skip to content
Download
USE CASE

Bulk edit database records, without writing SQL

Repricing a whole category, reassigning suppliers, fixing a bad batch of statuses. The usual answer is a hand-written UPDATE and a held breath. Workbook Connect lets you make the same change in Excel, see every row it touches, and commit it in one transaction.

Download free

Hundreds of rows, one commit

Filter to the rows in scope, edit them in the grid, and write the whole change back to your database at once. No staging table, no re-import.

EXCELDATABASE

Why the one-off UPDATE script is the worst part of the job

The request lands in chat: bump every accessory price by ten percent before Monday. So you write the UPDATE, eyeball the WHERE clause, and run a SELECT first to count rows because you have been burned before. The script works, until the day CategoryID 7 also quietly covers a discontinued range, or the ten percent should have been on cost not list price, and now four hundred rows are wrong with no preview, no per-row record of what changed, and a rollback that is its own small project. There is no margin check in a raw UPDATE either, so the one SKU priced below cost goes in with the rest and surfaces three weeks later in a margin report. You are not bad at SQL. The tool just gives you no chance to look before you leap.

The table you are actually changing

A category repricing touches DimProduct, keyed to DimCategory and DimSupplier. The foreign keys are what let Workbook Connect show you readable category and supplier names instead of raw IDs, and what keep every edited row pointing at something that exists.

∞1CategoryID∞1SupplierIDDimCategoryCategoryIDPKNameIsActiveDimProductProductIDPKCategoryIDFKSKUListPriceStandardCostDimSupplierSupplierIDPKName

An illustrative data model, not your exact schema.

Turn the change into a grid you can read

Point Excel at DimProduct, filter to the accessories category, and you get the affected rows in a real spreadsheet, with SKU, product name, cost, and list price laid out. Foreign-key lookups render CategoryID 7 as its actual name and the supplier ID as the supplier, so you are repricing recognisable products, not guessing at integers. Build the new price the way you always would: a working column with =[@StandardCost]*1.30, fill it down the filtered range, paste into ListPrice. The change is now concrete and in front of you, the full set of rows, before a single byte goes to the database. The filter, the lookups, the hidden technical columns, and the primary-key mapping are configured once and shared to the team on connect, so everyone who reprices opens the same guard-railed sheet.

A category repricing, mid-edit

Every row carries a status, the bulk change is right there to scan, and the one row priced below cost is rejected by a CHECK constraint on commit, blocking the whole commit until it is fixed, so nothing slips in unchecked.

Repricing-2026.xlsx, DimProduct
StatusSKUProductCostOld priceNew price
ChangedACC-1042Cable, USB-C 2m€ 3.10€ 6.99€ 7.69
ChangedACC-1043Cable, USB-C 1m€ 2.40€ 5.49€ 6.04
ChangedACC-1088Hub, 4-port€ 9.80€ 19.99€ 21.99
ChangedACC-1090Adapter, HDMI€ 4.20€ 8.99€ 9.89
Needs fixACC-1101Stand, laptop€ 14.50€ 12.99€ 14.29
ChangedACC-1120Pouch, sleeve 13"€ 5.00€ 11.99€ 13.19
Commit Validated, then written to dbo.DimProduct
  • Row 5: new price € 14.29 is below StandardCost € 14.50, so a CHECK constraint on the table (price must cover cost) rejects it on commit and the whole commit is blocked until this row is fixed. Nothing is written until every row passes, then they all commit together.

An illustrative example of the editing workflow, not a product screenshot.

Reviewed, validated, then committed in one transaction

Workbook Connect validates the whole sheet in Excel first against your rules, the foreign-key lookups, and each column type. A cross-column rule like price must cover cost is not a single-column rule, so it lives as a CHECK constraint on DimProduct, and the database rejects the laptop stand priced at 14.29 against a cost of 14.50 on commit. Either way, because one row fails, the commit is blocked and nothing is written. The failing row stays in the sheet with its reason. The per-row status column marks every line you touched as Changed or New, so the scope of the bulk edit is something you can read top to bottom instead of a row count you have to trust. Once every row passes, hit Commit and the whole change is written to DimProduct in a single transaction, under the permissions you already have. If a colleague repriced an overlapping range while you were working, optimistic concurrency flags those rows as conflicts rather than overwriting their work. Fix the price, commit again, done. No rollback project, no archaeology to work out what the UPDATE actually did.

Works with your database

FAQ

Bulk editing, answered

As many as your filtered view returns. A 600-row category repricing is a single edit pass and a single commit, the same workflow as fixing six rows. There is no batching to script and no UPDATE to chunk.

Every affected row is visible in the grid before anything is written, the per-row status column tells you exactly which rows changed, and your validation rules run first so a row that breaks a null check, or a database CHECK constraint like price must cover cost, blocks the commit with the reason. Nothing is written until every row passes, then they all commit together. A WHERE clause that is one predicate too wide shows up as extra Changed rows you can see and undo, instead of a silent commit you find out about next week.

Yes. You are in real Excel. Filter to a category, drop =[@StandardCost]*1.30 into a working column, paste the results into ListPrice, and let fill-down do the column. Workbook Connect reads the resulting values from the cells and commits those; the formulas stay in your sheet.

Optimistic concurrency catches it on commit. If a row changed in the database after you loaded it, that row is flagged as a conflict instead of overwriting the other person, so two people repricing overlapping ranges never silently clobber each other.

Only to the rows and columns your access already allows. Workbook Connect signs in with your existing authentication and every commit runs under your own database permissions, so it can never write anything you could not write yourself.

No. It reads and writes existing tables and makes no server-side schema changes. The configuration (filters, lookups, primary-key mapping, hidden columns) lives in Workbook Connect, not in your database.

Related use cases

Retire the one-off UPDATE script

Download Workbook Connect free, connect it to your database, and make your next bulk change in a grid you can see, validate, and commit in a single pass. The held breath is optional.

Download free