Safe Row Corrections in DataGrip: Read-Only Review to Guarded Commit

Correcting a single row in a production table is a high-risk, low-visibility task. A broad filter, an accidental submit, or a forgotten transaction can turn a one-row fix into a data incident. The safe pattern in DataGrip is to treat every production data source as read-only by default, isolate the exact rows by primary key, disable auto-commit for the writable step, and verify the result before you commit.

Desired Outcome

You want to change only the specific rows that need correction, with a clear before-and-after check and a deterministic way back. Instead of editing cells in a writable session or running an UPDATE with a loose WHERE clause, you will review the target set in a read-only connection, prepare one explicit statement, and either commit it after verification or discard it.

Prerequisites

• Least-privilege credentials. Use an account with SELECT access for review. Grant a narrow UPDATE privilege on the specific table only if a fix is truly required.
• A unique predicate. Identify the primary key column or a unique key for the target rows. Never rely on a non-unique filter such as a status or timestamp alone.
• Working connectivity. Confirm network, SSH tunnel, or SSL settings so the connection test passes before you begin.
• A tested recovery path. Know whether you can roll back the transaction, run a compensating statement, or restore from a backup or point-in-time recovery.

Step 1: Review the Target Rows in Read-Only Mode

Add the production data source in DataGrip and test the connection. Before opening any table, enable the read-only option in the data source settings. In current DataGrip versions this toggle is typically found in the data source properties under the Options tab, though the exact label and location vary by build. A read-only data source blocks accidental edits from that connection, but it does not remove privileges from the underlying database account and it does not prevent writes from other clients.

Open the table in the data editor and use column filters and sorting to isolate the candidate rows. Because filters can still match many rows if the predicate is broad, stop and confirm the exact set in the console with a primary-key predicate:

SELECT id, status, updated_at
FROM orders
WHERE id IN (1042, 1043);

Run this in the query console attached to the read-only data source. Record the row count and current column values. If the result set is larger than expected, refine the predicate until it matches only the rows you intend to change.

Step 2: Prepare the Guarded Edit

Prefer one explicit, reviewed UPDATE statement in the console rather than cell edits in the data editor. Before running it, disable auto-commit for that console session so the change stays inside a transaction until you explicitly commit. In DataGrip, auto-commit state is controlled from the console toolbar; the exact icon and default behavior differ across versions, so verify the current state in your build.

Write the statement using the same primary-key predicate you verified in Step 1:

UPDATE orders
SET status = 'shipped'
WHERE id = 1042;

If you must use the data editor instead, edit only the identified cells and rely on Undo or Rollback before submitting. Remember that the console and the data editor may use different sessions; a rollback in one does not cancel an uncommitted change made in the other.

Risk: Disabling auto-commit widens the transaction, so an uncommitted change can hold row or table locks. Keep the writable step short and never leave a session with pending changes.

Step 3: Review, Then Commit or Roll Back

Before committing, re-read the exact statement and confirm the affected row count matches your intent. If the effect is correct, commit. If anything is off, roll back and return to Step 1. Do not commit a change you have not verified.

Expected Checks

1. Re-run the same SELECT from Step 1 after committing and compare row counts and column values. The delta should be exactly the intended rows and nothing else.
2. Confirm no pending changes remain in the console or data editor.
3. Set the production data source back to read-only if you temporarily enabled write access.

Recovery Options

• Before commit: Use Rollback in the console or Undo in the data editor to discard the change.
• After commit: Apply a compensating statement that restores the previous values, or restore from backup or point-in-time recovery.
• Script control: Keep the reviewed statement under version control so it can be re-run or reversed deterministically.

Limitations and Verification

DataGrip's menu labels, the location of the read-only option, and auto-commit defaults vary by version. Confirm them in your build before relying on muscle memory. A read-only data source is a client-side guard, not a database privilege change.

To verify the workflow safely, reproduce it in a disposable database or clone: enable read-only, make an uncommitted edit, roll back, and confirm the target rows are unchanged. Then run the intended SELECT with the same predicate before and after a test change and compare counts and values.