Editing data

Edit results directly in the grid — then review the exact SQL before it touches your database.

Making edits

In an editable grid you can change a cell, add a row or delete a row. Modified cells are highlighted and the pending changes are counted, so nothing is written until you choose to save.

The save flow

Saving builds parameterised INSERT, UPDATE and DELETE statements for exactly the rows you changed — an UPDATE only sets the columns that actually changed, and an INSERT omits unset columns so the database applies its own defaults and auto-increments. By default the generated SQL is shown for review first; approving runs it all in a single transaction, and the grid re-reads afterwards to pick up database-assigned values. Save grid edits with Ctrl + Shift + S.

When is a grid editable?

Editing is enabled only when every column in the result maps back to a single table and at least one primary-key column is present (the key is how each row is matched for UPDATE and DELETE). Otherwise the grid stays read-only and shows the reason, for example:

• “Result has no primary-key column to identify rows.”
• “Result spans multiple tables.”
• “Result has no updatable table columns.”

A connection you've marked read-only is never editable, regardless of keys.

NoSQL engines

Document and key-value engines commit through a structured change set rather than generated SQL. Scope differs per engine: Redis and DragonflyDB edit hash fields in the grid (other types are changed via console commands); Elasticsearch writes back via _bulk, which is not transactional, so partial failures are reported per row.