Bulk operations

functional

Multi-select objects in the tree and script, export, or maintain them all at once.

Select several tables and views in the Object Explorer and act on all of them at once. Ctrl-click (Cmd-click on macOS) adds or removes one row. Shift-click selects every table and view between the last row you clicked and this one, in the order they appear on screen. A plain click, Esc, or the banner's ✕ clears the selection.

The keyboard does the same with the tree focused. Shift+↑/↓ (and Shift with Home, End, Page Up, or Page Down) selects every table and view between the row you started on and the row you move to; folders and servers along the way are skipped. Space adds or removes the highlighted row, and so does Ctrl+Space on Windows and Linux (on macOS Cmd+Space usually opens Spotlight, so use Space). Plain arrow keys move the highlight without dropping the selection, so you can walk to another row and add it with Space. While a selection is active, selected rows are filled and the highlighted row has an outline, so you can see when you've removed it. If you're typing a name to jump to a row, a Space within the same word is part of the name (for example Order Details), not a toggle. Esc clears the selection; if the tree is filtered, the first Esc clears the filter and the next one clears the selection.

While anything is selected, a banner above the tree shows how many objects are selected and the actions you can run on them:

Action	What you get
Script CREATE	One script with each object's live definition. Tables come first, each after the selected tables its foreign keys point to. Views and routines follow, each after the selected views and routines its definition refers to (a view over another view, or a view that calls a function). Where no dependency decides, objects keep the order you selected them in.
Script DROP	One script of guarded `DROP … IF EXISTS` statements in the reverse of that order: views and routines first, each before the selected objects it depends on, then tables with each child before its parent. That keeps foreign keys and dependencies between the selected objects from blocking a drop; an object outside the selection that still depends on one of them can still block it.
Export data…	Opens the table export dialog with exactly the selected tables ticked, on the connection and database they live in (an export dialog that is already open switches over). Views have no rows, so they are left out.
Maintenance…	Lists the engine's table maintenance operations (VACUUM, ANALYZE, UPDATE STATISTICS, OPTIMIZE TABLE, and so on) and scripts one statement per selected table.

Four tables multi-selected in the explorer, with the bulk-operations banner showing Script CREATE, Script DROP, Export data, and Maintenance.

How dependencies are found

Table order comes from the database's foreign keys. On an engine that can't list foreign keys, tables keep your selection order and the script header says so. View and routine order comes from reading each selected object's definition for references to the other selected views and routines. References inside comments and string literals don't count. Circular references can't be satisfied, so those objects keep your order and the script header carries a warning. For a DROP script, an object whose definition can't be read is still dropped, and the header warns that its position may not respect what depends on it.

Nothing runs without review

Every script action opens a new query tab on the connection and database where the objects live, not on whatever connection happens to be active. Nothing executes until you run the tab yourself. If the selection spans more than one database, you get one tab per database. Objects SQLly can't script, such as one whose definition it can't read or whose server didn't answer, appear as -- SKIPPED comments in the script and as a warning in the status bar and the script header. The rest of the script is still generated.

What stays selected

Collapsing a folder keeps its selected tables and views selected; the banner still counts them and the actions still include them. Rows that go away drop out of the selection: refreshing a folder or server clears the selection under it, disconnecting a server drops its rows, and removing a connection drops its rows.

Running an action uses up the selection, so running it again means selecting again. That stops an old selection from quietly driving a second script. Export data works on one database at a time. If the selection spans several, SQLly exports the first database and tells you which ones it left out.