SQL Workbench

A terminal front-end, swtui. The workbench runs in a terminal over SSH or on a server with no desktop: the same explorer, query tabs and compare tabs as the desktop, drawn in text. F2 adds a source, F3 opens a query on the selected source, F4 a compare, F5 or Ctrl+E runs or compares, F6 moves between the explorer and the tabs, Shift+F10 or the Menu key opens the explorer's menu for the selected row (new query, compare, refresh, remove, the script-as entries, diff with a counterpart), and the other tabs the desktop has say so until they get a terminal view of their own.

PostgreSQL shows what depends on what. The inspector's dependencies, "Show dependencies" in the explorer and the dependency order of a compare now work on PostgreSQL, read from the server's own catalogue: views over tables and views, materialized views, trigger functions, sequences a table owns, foreign keys and SQL-standard function bodies. A plpgsql body is not read, since the server never parses it, and a folder says it cannot answer.

"Select the first 1000 rows" limits on every engine. The explorer offered SQL Server's SELECT TOP 1000 on PostgreSQL, MySQL and SQLite tables, and the statement it opened there had no limit at all. It now ends in LIMIT 1000 on those three, SQL Server keeps its TOP, and the entry has one name everywhere.

A MySQL table's AUTO_INCREMENT counter is no longer part of its script. Two tables with one definition and different row histories compared unequal, and a folder under version control changed with every insert. Export no longer writes the counter and compare ignores it where a folder or dump still carries it; a column's own AUTO_INCREMENT stays.

Completion on one letter stays readable. A connected PostgreSQL offers about 2,700 functions, and Ctrl+Space on "p" listed 475 of them. A word shorter than three letters now gets at most a hundred functions — the word itself, the dialect's own, then the shortest names. Three letters or more still offer every function that fits; keywords, snippets and the schema's names are never cut.

The knowledge pack editor saves archives and builds packs. A pack kept as one .knpack can be saved, written beside the original and swapped in only once complete. Tables, rules, relations and dictionary queries can be added and removed; a rule and a relation are asked for in a form, and a relation's tables and columns can be corrected, with the open database's names offered as you type. Nothing is written unless the pack still loads.

Dictionary queries show what they produce. Running one lists the tables and columns the pack would know from it, with description, unit and code source, and "Check the code queries" runs each column's code query the way a reader would and marks what came back — codes, none, the engine's refusal, a write it held back, or a parameter with no default.

Safe mode asks SQLite which statements write. On a guarded environment a SQLite query is also checked by SQLite itself, so a write behind a reading first word (WITH … DELETE) is held. swcli --help describes SQL Server, PostgreSQL, MySQL and SQLite rather than SQL Server alone.

A target that changes while its plan is made is compared once more. SQL Server refuses to script against a database whose catalogue changed after the comparison — a login created anywhere on the server is enough. Generate script and sync now compare again once on that refusal and explain a second one in plain words; running an existing plan says it has to be made again.

A SQLite file is no longer "unreachable". A query tab on a sqlite:// file, or a compare with one as a side, used to stop at "Server unreachable": the two-second reachability check was handed the connection string alone and read it as a SQL Server address. The check now knows the engine, so a file is reachable when it exists.

A password typed without :// is hidden like any other. An address such as app:secret@host or postgres:/app:secret@host came back verbatim in labels and in the session file. Such passwords are now scrubbed too, half-typed ones included; drive letters and real paths are left alone.

PostgreSQL databases can be made to match. Sync, Dry run and Generate deploy script are no longer greyed out for a PostgreSQL pair: the tool writes the DDL itself — ALTER TABLE column by column, CREATE OR REPLACE for a view whose columns stand still, drop and create where nothing gentler exists — everything that goes before everything that arrives, each in dependency order. A folder target is written as the mirror it is.

MySQL databases can be made to match, and you are told first that it cannot be undone. plan, script and sync reach a MySQL target: ALTER TABLE key by key, views replaced, routines, triggers and events dropped and recreated, tables in foreign-key order. MySQL commits each DDL statement as it runs, so every plan, dry run, confirmation and generated script says so before anything starts, and --transactional is refused with the reason rather than quietly ignored.

Data compare and sync on PostgreSQL and MySQL. A table's rows are compared and synced on both engines, from a database or from a folder of their rows, so a folder exported from either no longer comes back with every lookup table empty. A row that already matches is not written again — no trigger fires and no timestamp column moves for it — so a sync that finds nothing to do touches nothing.

Table data as JSON, CSV or TSV. Data export and sync can write a table's rows as a JSON file naming the table, its key and its column types (--data-format json), as bare JSON rows, or as CSV or TSV, one file per table in {Schema}/Data/; a .json, .csv or .tsv destination takes every table in one file. Such a file is a data side of its own — swcli data compare ./seed.json @uat/AppDb — and lists its own tables when nothing else names any. SqlDeploy's two layouts read as SqlDeploy reads them: a file named dbo.Config.json, and one whose rows each say their Table. A file that carries no types is read as the other side's, so "2026-01-01 08:00" equals a datetime2, and takes its key from there. The data compare tab has an Export as choice, query results save as a JSON data file, and Import data opens one with its tables as the sheets. Reading these files back is SQL Server's for now.

Completion knows what your database has installed. A PostgreSQL with an extension offers that extension's functions, with the argument list and comment the server keeps; MySQL and SQLite offer the keywords and functions their own catalogues list. And on all three, your tables and columns now come before the language's keywords in the list, as they always did on SQL Server.

A deployment that was never scripted is no longer reported as done. With several deployments in one process, the engine could refuse to script one of them, and the run went on to publish only the pre- and post-deployment scripts and call it a success. The refusal is now a blocking warning on the plan, with the engine's own message.

A SQLite alias with a database beside it opens no other file. @lite/other used to open a file called other in the working folder; it now refuses, naming the alias. An unknown --engine name is refused when it is typed rather than later.

swcli help prints the example a topic is written around, as the Help tab already did.

PostgreSQL, to browse and to query. Register a connection with alias add pg "Host=myserver;Username=app;Database=AppDb" --engine postgres --database AppDb, or write the address as postgres://app@myserver/AppDb, and the explorer reads the database: schemas, tables with their constraints, indexes and triggers, views and materialized views, functions and procedures, and sequences, each as the server's own DDL with every name schema-qualified. A query tab runs scripts against it, a notice raised mid-batch prints where it happened, and an error points at the line it is on. Databases can be listed and a server can be tested (alias test). Comparing, deploying and data sync stay SQL Server's for now, and the actions that need them are greyed out with a reason.

MySQL, to browse and to query. The same as Postgres, through alias add my "Server=myserver;User ID=app;Database=AppDb" --engine mysql --database AppDb or mysql://app@myserver/AppDb: the explorer reads the database's tables (keys and indexes inside them, as MySQL writes them), views, procedures, functions, triggers and scheduled events, each as the statement the server itself prints. A query tab runs scripts against it, DELIMITER $$ in a script does what the mysql client does with it, and a failed statement carries the engine's own error number. A database here is what a schema is elsewhere, so the explorer groups under the database's name.

SQLite, to browse and to query. A database is a file, so there is nothing to reach: alias add lite "Data Source=/home/me/app.db" --engine sqlite, or write it as sqlite:///home/me/app.db. The explorer reads the tables — with their indexes and triggers, exactly as they were written, since SQLite keeps the statement it was given — and the views, under main. A query tab runs scripts against it, and a CREATE TRIGGER … BEGIN … END; counts as the one statement it is. A file that is not there reads as not there, rather than as a server that will not answer.

A primer for the engine you are on. F1 on a PostgreSQL or MySQL tab now answers the question a developer actually asks — how a CTE is spelled here, what this engine's upsert is, how temporary tables and indexes are written, what happens to a name you did not quote — in about forty topics per engine, each with a worked example. They are written for someone who knows SQL and not this engine, they say what the engine does not have as plainly as what it does, and every example in them is run against a real server by the build, so an example that stopped working cannot ship. On PostgreSQL they sit in front of the statement pages, so the grammar is still one search away.

MySQL explains itself out of your own server. MySQL's manual is not ours to ship, but a stock MySQL server carries it: the tables behind its own HELP statement, around 700 topics. Where the connection in front of you has them, they are read once and answer beside the primer — held in memory, written to no file — and the Help tab says which answer came from where. A server whose help tables were never filled is not an error; you simply keep what the build carries.

A folder of scripts reads back on the new engines. PostgreSQL, MySQL and SQLite could write a database out to a folder but never read one in, so everything standing on a folder was SQL Server's alone. Now a clean folder or a dump file reads back on all three: comparing a PostgreSQL database against a checkout is a comparison rather than a refusal, a table keeps the indexes and constraints written under it, and each object keeps the file's own text, comments and terminators included. A file whose statements name nothing is reported rather than quietly skipped, because next time it would read as a deletion.

Knowledge packs can be read and corrected inside the product. A pack is a folder of hand-written JSON, and a real one runs to a hundred and forty files. Settings now offers Edit beside every pack that loaded: the tree of files it is written in, an editor for the one picked, and a save that writes only the file it changed, so the names and groupings its author chose survive. Before the disk sees anything the whole pack is loaded as it would be afterwards, and a change that would not load leaves its reasons on screen and the file untouched. With a database of the pack's engine open, Check marks every table and column the pack names and the database has not, and Check codes reads what a column actually holds — one read-only SELECT DISTINCT at a time.

PostgreSQL's own documentation ships with it too. F1 on a Postgres tab explains a statement in PostgreSQL's own words, with the syntax it publishes and what each parameter means: 185 statements, 87 KiB, offline. Its functions are documented as tables rather than pages and are not in the pack yet, so those still show only their names.

SQLite's own documentation ships with it. F1 and hover explain a SQLite statement, function or pragma out of SQLite's own words — 227 entries, 18 KiB, offline — and Ctrl+Space shows a function's signature and what it does. SQLite's documentation is public domain, which is why this one could be included; the importer refuses any documentation whose licence does not say as much.

The engine checks your SQL, without running it. A moment after the editor's own squiggles, the engine itself is asked about each statement — by preparing it, which parses it and resolves every name and column and executes nothing. So select * form customers is marked under form, and a column or table that is not there is caught with the engine's own words, on PostgreSQL, MySQL and SQLite. SQLite answers in microseconds because it is built into the application. A statement MySQL will not prepare is left unmarked rather than called wrong, the check never runs on the connection your tab is using — so an open transaction of yours is never disturbed — and typing on cancels a check in flight.

The editor knows what it is looking at on the new engines. A literal or comment left open, a bracket that does not match, and a table the database does not have are all marked where they stand — and a name that is in the database is coloured as one. Ctrl+Space offers a table's columns behind its alias, the knowledge packs' codes and column meanings work, Select and Insert templates are offered from the explorer, and "execute the statement under the caret" follows the engine's own idea of a statement, DELIMITER $$ bodies and SQLite triggers included. Writing a result back stays SQL Server's: telling which table a column came from needs a parser these engines do not ship, and the editor says so rather than guessing.

A name that is a reserved word is quoted, on every engine. The keyword lists the new engines shipped were written by hand and fell short of what the engines actually reserve — 70 words for PostgreSQL, 96 for MySQL, 17 for SQLite — so a table called authorization or a column called dual was scripted bare and the engine refused it. Each list now comes from the engine itself and is checked against it.

Language help answers as the engine in front of you. The Help tab used to show T-SQL whatever the tab was connected to. F1 on a Postgres tab now opens Postgres's own reference, and an engine this build carries nothing for says so plainly rather than explaining another engine's language.

The connection editor knows which engine it is writing for. Connections gains an Engine picker as soon as the build can open more than one, and everything on the page follows it: the sign-on kinds it offers, the keywords it writes, and whether there is an Encrypt option at all. Test connects through that engine's own driver and says which engine and version answered.

PostgreSQL, to browse and to query. Register a connection with alias add pg "Host=myserver;Username=app;Database=AppDb" --engine postgres --database AppDb, or write the address as postgres://app@myserver/AppDb, and the explorer reads the database: schemas, tables with their constraints, indexes and triggers, views and materialized views, functions and procedures, and sequences, each as the server's own DDL with every name schema-qualified. A query tab runs scripts against it, a notice raised mid-batch prints where it happened, and an error points at the line it is on. Databases can be listed and a server can be tested (alias test). Comparing, deploying and data sync stay SQL Server's for now, and the actions that need them are greyed out with a reason.

MySQL, to browse and to query. The same as Postgres, through alias add my "Server=myserver;User ID=app;Database=AppDb" --engine mysql --database AppDb or mysql://app@myserver/AppDb: the explorer reads the database's tables (keys and indexes inside them, as MySQL writes them), views, procedures, functions, triggers and scheduled events, each as the statement the server itself prints. A query tab runs scripts against it, DELIMITER $$ in a script does what the mysql client does with it, and a failed statement carries the engine's own error number. A database here is what a schema is elsewhere, so the explorer groups under the database's name.

SQLite, to browse and to query. A database is a file, so there is nothing to reach: alias add lite "Data Source=/home/me/app.db" --engine sqlite, or write it as sqlite:///home/me/app.db. The explorer reads the tables — with their indexes and triggers, exactly as they were written, since SQLite keeps the statement it was given — and the views, under main. A query tab runs scripts against it, and a CREATE TRIGGER … BEGIN … END; counts as the one statement it is. A file that is not there reads as not there, rather than as a server that will not answer.

A primer for the engine you are on. F1 on a PostgreSQL or MySQL tab now answers the question a developer actually asks — how a CTE is spelled here, what this engine's upsert is, how temporary tables and indexes are written, what happens to a name you did not quote — in about forty topics per engine, each with a worked example. They are written for someone who knows SQL and not this engine, they say what the engine does not have as plainly as what it does, and every example in them is run against a real server by the build, so an example that stopped working cannot ship. On PostgreSQL they sit in front of the statement pages, so the grammar is still one search away.

MySQL explains itself out of your own server. MySQL's manual is not ours to ship, but a stock MySQL server carries it: the tables behind its own HELP statement, around 700 topics. Where the connection in front of you has them, they are read once and answer beside the primer — held in memory, written to no file — and the Help tab says which answer came from where. A server whose help tables were never filled is not an error; you simply keep what the build carries.

A folder of scripts reads back on the new engines. PostgreSQL, MySQL and SQLite could write a database out to a folder but never read one in, so everything standing on a folder was SQL Server's alone. Now a clean folder or a dump file reads back on all three: comparing a PostgreSQL database against a checkout is a comparison rather than a refusal, a table keeps the indexes and constraints written under it, and each object keeps the file's own text, comments and terminators included. A file whose statements name nothing is reported rather than quietly skipped, because next time it would read as a deletion.

Knowledge packs can be read and corrected inside the product. A pack is a folder of hand-written JSON, and a real one runs to a hundred and forty files. Settings now offers Edit beside every pack that loaded: the tree of files it is written in, an editor for the one picked, and a save that writes only the file it changed, so the names and groupings its author chose survive. Before the disk sees anything the whole pack is loaded as it would be afterwards, and a change that would not load leaves its reasons on screen and the file untouched. With a database of the pack's engine open, Check marks every table and column the pack names and the database has not, and Check codes reads what a column actually holds — one read-only SELECT DISTINCT at a time.

PostgreSQL's own documentation ships with it too. F1 on a Postgres tab explains a statement in PostgreSQL's own words, with the syntax it publishes and what each parameter means: 185 statements, 87 KiB, offline. Its functions are documented as tables rather than pages and are not in the pack yet, so those still show only their names.

SQLite's own documentation ships with it. F1 and hover explain a SQLite statement, function or pragma out of SQLite's own words — 227 entries, 18 KiB, offline — and Ctrl+Space shows a function's signature and what it does. SQLite's documentation is public domain, which is why this one could be included; the importer refuses any documentation whose licence does not say as much.

The engine checks your SQL, without running it. A moment after the editor's own squiggles, the engine itself is asked about each statement — by preparing it, which parses it and resolves every name and column and executes nothing. So select * form customers is marked under form, and a column or table that is not there is caught with the engine's own words, on PostgreSQL, MySQL and SQLite. SQLite answers in microseconds because it is built into the application. A statement MySQL will not prepare is left unmarked rather than called wrong, the check never runs on the connection your tab is using — so an open transaction of yours is never disturbed — and typing on cancels a check in flight.

The editor knows what it is looking at on the new engines. A literal or comment left open, a bracket that does not match, and a table the database does not have are all marked where they stand — and a name that is in the database is coloured as one. Ctrl+Space offers a table's columns behind its alias, the knowledge packs' codes and column meanings work, Select and Insert templates are offered from the explorer, and "execute the statement under the caret" follows the engine's own idea of a statement, DELIMITER $$ bodies and SQLite triggers included. Writing a result back stays SQL Server's: telling which table a column came from needs a parser these engines do not ship, and the editor says so rather than guessing.

A name that is a reserved word is quoted, on every engine. The keyword lists the new engines shipped were written by hand and fell short of what the engines actually reserve — 70 words for PostgreSQL, 96 for MySQL, 17 for SQLite — so a table called authorization or a column called dual was scripted bare and the engine refused it. Each list now comes from the engine itself and is checked against it.

Language help answers as the engine in front of you. The Help tab used to show T-SQL whatever the tab was connected to. F1 on a Postgres tab now opens Postgres's own reference, and an engine this build carries nothing for says so plainly rather than explaining another engine's language.

The connection editor knows which engine it is writing for. Connections gains an Engine picker as soon as the build can open more than one, and everything on the page follows it: the sign-on kinds it offers, the keywords it writes, and whether there is an Encrypt option at all. Test connects through that engine's own driver and says which engine and version answered.

A database icon beside the connection box says where the tab stands. Grey when it is not connected, green when it is, blue while it is connecting or the box names somewhere the session is not yet, red when the last connect failed — with the details in its tip.

Tabs reconnect when you come back to them. A tab that was connected when the application closed connects again the first time you look at it after a restart; tabs you do not open stay closed, and one that cannot connect shows red.

Changing the connection box changes the connection. On a connected tab, the box takes effect when you press Enter or leave it: another database on the same server is switched to on the same session — open transactions and temp tables stay — and anything else reconnects. Execute applies a change first. With a transaction open, a change of server waits for you to commit, roll back or press Connect. Shift+Tab at the very start of the script, with nothing left to outdent, goes up to the box, and Down from the box or any button above the script goes back into it.

A relation a pack describes can hold for some rows only. A pack's relation may say "when": { "SubjectKind": 1 }: the type column beside a key that points at a different table for every type. The join and the ON clause the editor writes carry it — on r.SubjectId = i.Id and r.SubjectKind = 1 — and the inspector and swcli relations show it. Numbers are written as numbers, text as a string.

A coded column offers its codes as you type its value. where Status = opens the column's code list as soon as the space is typed, and Ctrl+Space there does the same with the first code chosen. It used to stay shut in a new tab until something had been hovered, and for a statement still waiting for its value, which is exactly when it is wanted.

Install a knowledge pack from the application. Settings → Knowledge packs lists every pack it can see — what it holds, where it came from, and why it was refused where it was — and installs one from a .knpack, a zip or a folder. A pack that cannot be read is refused before anything is copied, one of the same name asks before it is replaced, and Remove takes away one you installed. A pack shipped with the application, or named in the configuration, is listed but left alone. Changes apply without a restart.

Every result of a script shows its rows. A script whose statements all returned at once — select 'a' twice, in one batch — showed the first result and an empty second one. Each result set is now put on screen as it finishes, and the run's last word on them waits for the window rather than racing it.

Install a knowledge pack from the application. Settings → Knowledge packs lists every pack it can see — what it holds, where it came from, and why it was refused where it was — and installs one from a .knpack, a zip or a folder. A pack that cannot be read is refused before anything is copied, one of the same name asks before it is replaced, and Remove takes away one you installed. A pack shipped with the application, or named in the configuration, is listed but left alone. Changes apply without a restart.

Every result of a script shows its rows. A script whose statements all returned at once — select 'a' twice, in one batch — showed the first result and an empty second one. Each result set is now put on screen as it finishes, and the run's last word on them waits for the window rather than racing it.

Quick reports. A script with a -- ##QR: line is a report: Execute report (beside Execute, in the editor's menu and in the palette) runs it with every row kept and writes an Excel workbook, a sheet per result set, laid out the way QuickReport laid them out. -- ##QR: Name = sales names the file, AddDate = true dates it, FreezeColumns = 2 and Format Amount = #,##0.000 shape the sheets, and -- ##QR: PageName = Summary names the next result set's sheet. A first column called ##PAGENAME names its sheet from the data instead, and is not written; a script that uses one is a report without any ##QR.

Settings in sections. The Settings page lists its sections on the left — General, Editor, Query and results, Explorer, Storage, Notifications, Keyboard shortcuts — and shows one at a time, instead of one page that scrolled for a dozen screens.

Alt+Space on a selection is about the selection. With text selected, the list starts with Format selection and Execute selection, then what applies at the caret. The editor's right-click menu has Format document (or Format selection) too, and Execute selection while something is selected; the Ctrl+Space list shows a column the way it will be written, o.Total under its table's alias.

The code actions ask instead of listing everything. The context menu and Alt+Space now show one line per kind of thing — Expand * …, one Add columns …, one Add a join … — so a sixty-column table with eight relations is two lines. The join dialog starts with the related tables: type to narrow them, Up and Down to pick. Expand and Add columns open a checklist of the columns with their type and what the knowledge packs call them: type to filter, Space to tick, Ctrl+A for all or none, choose one line, one per line or a wrap width, and watch the text in the preview. Join asks inner, left, right or full outer — left already chosen where the referencing column may be null — lets you change the alias (it tells you when the statement already uses it), and picks between several relations to the same table, each named with its foreign key and marked where a pack describes it. Where a join could take more than one ON, Write the ON clause … asks which. Everything works from the keyboard, OK is one undo step and leaves the caret after what was written, and Escape changes nothing.

A joined table gets an alias that reads like it. Add join strips the prefix a system puts on every table and takes the initials of the words in the name, so app_customeraccountlink is joined as cal rather than a, a2, a3. The words of a name written all in lower case are found from the database's own table and column names, with nothing to configure; a knowledge pack can add prefixes and words of its own, and so can you in the editor settings. An alias the script already gives the table is used again, and a reserved word is never proposed. Join aliases on the Settings page brings back the first letter, or writes the whole name.

You choose how the editor lays out SQL. A sixty-column Expand * no longer lands on one line nobody reads: lists the editor writes now wrap at 100 columns, aligned under the first column wherever in the line the star stood, with the editor's own tabs or spaces. The new Formatting group on the Settings page switches that to one line or one item per line, sets the width, and puts the comma — or the AND between the pairs of a join — at the end of a line or the start of the next. The same group sets what Format Document does: keyword casing, indentation, aligned clause bodies, which clauses start a new line, one select item or WHERE predicate per line, AS on its own line, and semicolons. Leave them alone and it formats exactly as before; comparing scripts is not affected.

The editor writes the columns and the join for you. Alt+Space (or Ctrl+., where the desktop keeps Alt+Space for itself) and the editor's context menu offer what applies at the caret. Expand * writes out the columns of the tables the statement reads, under the aliases it uses — select * from Invoice i becomes select i.Id, i.Status, … — and brackets a name only where it needs them. Qualify gives a bare column its alias, Add column lists the ones not selected yet, and Add join offers one entry per relation to a table not yet in the query and writes the whole join, with an alias that is free and every pair of a composite key. After join Customer c, after a bare ON, and in a WHERE, it offers the predicate between tables already there. A relation a knowledge pack describes is offered too and says so; where nothing relates two tables, nothing is offered rather than guessed. Each is one undo step, a right-click acts where you clicked, and none of it reads the database while you type.

Delete the star to see the columns. With the select list empty, Ctrl+Space — or the first letters of a name — offers the columns of the tables in the FROM clause ahead of everything else, each once and with its table and type beside it. A statement with a hole in it no longer has to parse for the editor to know what it reads.

Alt+F1 opens a page, and a column has one of its own. The inspector opens on what an object is: its description, its columns, and the relations it takes part in, in both directions — Enter on one opens the table at the other end. The script waits behind Show script and the dependency lists behind Show dependencies (also in the explorer's menu), so opening the page reads nothing it was not asked for; it used to read the database's whole dependency graph every time. Alt+F1 on a column opens that column's page: its type, its description and unit, its code list in full, its relations, and a way back to the table. A coded column explains itself with the same card the editor shows — rest the pointer on the row, or press F1 — and the card never takes the keyboard from the list.

The card under the pointer can be used. More… on a keyword's card and … N more under a long code list are buttons you can reach and press: the card stays while the pointer travels to it, and a press inside it lands. … N more opens the column's page, where the list is whole.

Relations. swcli relations @uat/AppDb [dbo.Invoice] lists which columns join which tables. Foreign keys are read from the database; for a database that declares none, a knowledge pack can describe them in relations/*.json, and every list says which is which.

A knowledge pack can be one file, and any table can be described. A pack folder zipped — .knpack or .zip — is read wherever a folder is, and knowledge export -o ledger.knpack writes one. A table whose name a file system cannot spell (a dot inside it, a character it forbids, letters outside ASCII) is described by a file that names its schema and table itself; an exported pack writes such files that way, so it reads the same on another machine.

Native Wayland, if you want it. On Linux, Settings → Windowing backend → Wayland (or SVALEFELT_SQL_BACKEND=Wayland for one start) runs the window without XWayland where a compositor answers, and on X11 as before where none does. The page and the system report name the backend the running window actually got. Under Wayland the compositor sets the scale of each screen, so the scale setting says it does not apply.

The window reopens where it was left, unless you would rather it did not. Reopen the window where it was left is a setting now. A desktop that places windows itself — a tiling one, or Wayland, where a window may not choose its position — has the last word, and the setting says so.

A newer toolkit underneath. The application runs on Avalonia 12 and every package it uses is on its latest version. What the toolkit itself has to say — a renderer that gives up, a backend that falls back — now reaches the application's log file, where it used to go nowhere.

A pack can ask the database about itself. Some systems carry their own field dictionary: a table of fields with labels and the lookup each column uses, and description tables beside the configuration tables. A pack now lists dictionary queries that read it, so the descriptions and code lists are the installation's own and never a snapshot, and declares parameters such as @language that config.json, a connection or a project file set; swcli knowledge list @uat/AppDb shows what each query contributed and which language is in effect, and knowledge export --from-pack writes the answer down as static files.

The Compare tab counts what is ticked. After a compare the footer read 0 of 0 selected and the button Sync 0 objects while the rows were ticked; the sync itself acted on the ticks, so only the count was wrong. It is right now, and Sync and Preview are not offered while nothing is ticked. The two scripts share the diff pane evenly whatever the longest line is, a long line scrolling inside its own half; the take marks are large enough to hit; Options sits beside the source boxes, so the object list is two rows taller.

A confirmation can be read. The sheet before a sync, in the Compare tab and in the Data compare tab, stays inside the tab: warnings wrap, the box for the environment's name takes the sheet's width, and a long list of changes scrolls instead of pushing the buttons away.

Data compare reads in the dark theme. Inserted, updated and deleted rows take their colours from the theme, and the key line under the selected table is legible.

Save as data set. The Data compare tab can save the ticked tables as the data set, into the folder's project file when a side is a folder and into your own configuration otherwise, and says where it wrote. swcli data compare|export|sync then sees the same tables, and a new tab starts from them.

Badges stay whole in a narrow explorer. Environment and counterpart badges sit at the row's right edge and keep their width; the name gives way with an ellipsis. The tree no longer scrolls sideways.

A source can be written as a URL. sqlserver://myserver/AppDb, and jdbc: addresses too, are read into the ordinary connection string; swcli alias add takes one, and --engine names the engine of an alias. A password written into such an address (anything with :// in it) is not shown, logged or saved, whatever punctuation the password holds and even while it is half typed. Several older messages that repeated a typed source as it was written now show its server and database instead.

A database explains itself as soon as it is opened. The explorer's tooltips carry a knowledge pack's descriptions once you open the database, without a query tab having connected to it first. Nothing is resolved when the application starts, and a filter that opens many rows at once reaches no server: a pack that recognises its system with a query waits until you open that database yourself.

The plain-text password warning is said once per swcli call, not twice.

The editor shows what the packs know. Resting the pointer on a column shows its description and its code list, on a literal compared with a coded column it shows 3 = Posted (the status bar says the same while the caret is on it), completion after = or IN ( offers the codes, and Alt+F1 on a column opens the inspector with the description and codes beside every column.