Data and editing

studiodataeditinggrid

Two grids, sharing most of their behaviour. The result grid shows what a query returned. The table editor shows a table and can write to it.

Double-click a table in the tree for the editor, or middle-click for one that opens behind what you are doing.

Paging

Rows are read a page at a time from the server side rather than pulled down in full, so opening a table with millions of rows in it is instant and stays that way. The footer says what the page holds; the total is a click away rather than automatic, because counting a table is work and the number is rarely what you opened it for. Both are shown once you ask, and the difference between them is what matters when exporting.

How the next page is found depends on the table. With a single-column primary key it starts from the last row seen, which costs the same whatever page you are on. Without one there is nothing to resume from, so paging deep into the table gets slower as you go, and the editor says why rather than leaving you to wonder.

Editing

Edits accumulate rather than being written as you make them.

Key Does
Ctrl+S Apply everything pending, as one transaction
Escape Discard everything pending
Delete Delete the row

The tab carries a dot and the toolbar an Unsaved changes badge while anything is pending, which is how you tell a tab you have edited from one you have only read. A deleted row leaves the grid at once and the row count drops with it; nothing has been written until you apply, and discarding brings it back.

Applying sends the whole set in one transaction, so either all of it lands or none of it does. Closing a tab with unapplied changes asks first, and so does closing the window.

Tables you can read and not write

A table with no primary key opens for reading and says so, rather than accepting typing into a cell that cannot be saved.

An update has to name the row it is changing, and without a key there is nothing to name it by: two rows with identical values are the same row as far as SQL is concerned, and Studio will not guess which one you meant.

Adding a key makes it editable, and is worth doing anyway. Without one, inserts also slow down as the table grows, since the engine has no key to place a row by. See indexing.

When the database disagrees

If a row moved between your reading it and your applying, the apply stops and shows both values: what you typed, and what is there now. Re-read takes the database's version and drops yours; Apply over writes yours on top. Nothing has been written when the question is asked.

This is the engine's own conflict detection surfacing. Under MVCC a write conflict is found at commit rather than at the write, and the grid is showing you the same conflict your application code would have to handle. See transactions.

Copying out

Right-click, or Ctrl+C for the selection.

Command Gives you
Copy The selected rows, tab separated
Copy with Headers The same, with a header row
Copy as INSERT The selected rows as INSERT statements
Copy All Rows Everything on the page
Copy All as INSERT Everything on the page, as statements
Export Results The export dialog

Copy as INSERT is the one that saves time: three rows from one database become three statements you paste into another.

How values are shown

Dates, numbers and binary values are rendered according to settings rather than to the machine's locale, so a screenshot means the same thing on two machines and a copied value is the value. Binary can be shown as hex, as base64 or as a size.

Nulls are rendered distinctly from empty strings, which is the distinction most grids lose. An empty string and a single space are not yet told apart, and a BOOLEAN is drawn as text rather than as a checkbox.

Rebuilding a table

Some changes to a table cannot be made in place and need it rebuilt. Studio plans that rather than running it, and the plan is on the schema page.

Where to go next