On this page

What's new ?

Last published release: 5.3.0. This page lists every change you can see in BroadSQL since that release, grouped by area. It is updated with each change, becomes the basis of the next release notes, and starts again from that release once it is published. What each release contained is in the release notes.

WORLD sample database
Interactive console and help
Colors and table layout
TAB completion
Exploring a database
Connections and Environments
Export
Scripts, files and list sources
BroadSQL Editor
Settings and startup
Installation and packaging
Extensions

WORLD sample database

BroadSQL includes a sample database: `CONNECT WORLD;`

What changed: a fresh installation includes WORLD, an H2 sample database of countries, cities, languages, currencies and regions, with its connection already defined.
How you see it: CONNECT WORLD; works right after the first login and the prompt becomes WORLD>. The database is the file samples/WorldDB.mv.db of the installation folder (URL jdbc:h2:./samples/WorldDB, user sa, no password, Environment LOCAL, no Database Group). It can be modified freely, and restored by replacing that file with the one from the download.
Syntax or setting: CONNECT WORLD;
How to verify: on a fresh installation, log in and run CONNECT WORLD;, SHOW TABLES; (CITY, COUNTRY, COUNTRYLANGUAGE, CURRENCY, REGION and a few others), DESCR COUNTRY; and SELECT * FROM COUNTRY;.
More: Getting started

Interactive console and help

The JLine console is the standard console

What changed: the interactive console with history, line editing, TAB completion and colors is now on by default.
How you see it: with no activatejline line in BroadSQL.ini, BroadSQL starts with the interactive console instead of the basic one.
Syntax or setting: activatejline=ON (default); activatejline=OFF keeps the basic console.
How to verify: remove activatejline from BroadSQL.ini, start BroadSQL, press Up: the previous command comes back.
More: Interactive console, Application settings

Esc cancels the whole statement, Ctrl+U deletes to the start of the line

What changed: Esc abandons everything you are typing, including the earlier lines of a statement not yet ended with ;. Ctrl+U deletes from the cursor back to the beginning of the line.
How you see it: after Esc, the prompt is empty; nothing runs and nothing is added to history.
Syntax or setting: keys Esc and Ctrl+U.
How to verify: type SELECT *, press Enter, type FROM T, press Esc, then type SELECT 1;: only SELECT 1 runs.
More: Keyboard shortcuts

`HELP SHORTCUTS;` lists the keyboard shortcuts

What changed: a new help topic shows every keyboard shortcut of the console, with or without a database connection.
How you see it: a KEY / SHORTCUT | ACTION table, then the keys that depend on your terminal. HELP FIND keyboard and HELP FIND shortcut point to it.
Syntax or setting: HELP SHORTCUTS;
How to verify: start BroadSQL without connecting and type HELP SHORTCUTS;.
More: Keyboard shortcuts, HELP

`HELP;` is shown as tables

What changed: HELP; no longer starts with the banner. It shows two tables: the command categories with their alias and description (then the Patterns and Shortcuts topics), and the forms of HELP. HELP ALL; and the other forms of HELP are unchanged.
How you see it: the same bordered | and - tables as query results, following the width of the window.
Syntax or setting: HELP;
How to verify: type HELP;: the first line is a table border, and the last table has a HELP SHORTCUTS row.
More: HELP

The API Client category is described in plain words

What changed: the description of the API Client category in HELP no longer contains internal development wording.
How you see it: HELP; and HELP API; describe the category as "Configure, import, browse and execute HTTP API endpoints with the Universal API Client."
Syntax or setting: HELP API;
How to verify: type HELP; and read the API CLIENT row.
More: HELP

Colors and table layout

One table format for query results and commands

What changed: query results now have the same borders as the tables of BroadSQL commands: every line starts and ends with |, and a border line closes the table after the last row. SHOW DRIVERS no longer starts its lines with ||, and SYNC TYPE CATALOG shows the current types as a table instead of space-aligned columns.
How you see it: |--|----| above and below the header and after the last row of every table. Values, column widths, the number of rows and exports are unchanged; the vertical layout of narrow windows is unchanged too.
Syntax or setting: ScreenSeparator still chooses the separator of query results (default |).
How to verify: run SELECT 1 AS ID, 'A' AS NAME; and LIB LIST;: both tables have the same borders.
More: Table layout and window width

Colors, themes and a colored prompt

What changed: what you type is highlighted, ERROR, WARNING, INFO and success messages are colored, and the prompt is colored, with a distinct style when the connection's Environment is flagged Production. The prompt looks the same before your input and at the start of the lines BroadSQL prints.
How you see it: colors in the interactive console when the terminal supports them.
Syntax or setting: color (AUTO, ON, OFF) and theme (default-dark, default-light, classic, high-contrast-dark, high-contrast-light, mono, none).
How to verify: set theme=default-light, restart, and run SELECT 1;; set theme=none or color=OFF to go back to plain text.
More: Colors, themes and highlighting, Application settings

Result tables follow the window width

What changed: tables adapt to the width of the terminal window.
How you see it: in a narrow window, wide columns are narrowed and long values are shortened with a trailing ~; when even that cannot fit, each row is shown vertically. Exports and <@last:...> always keep the full values.
Syntax or setting: displaymode (AUTO, COMPACT, NORMAL, WIDE).
How to verify: narrow the window below 80 columns and run a query with long values.
More: Table layout and window width

TAB completion

More names and paths are completed

What changed: TAB completes table names wherever a command expects a table of the current connection (DESCR, SHOW PK, SHOW FK, SHOW REFERENCES, SHOW INDEXES, DUMP, LOAD, ALL, CNT and COMPARE TABLE STRUCTURE), also after a schema and a dot (sales.o<TAB>), DUMP's sources, TO, AS and formats, Scripts Library names after DUMP LIB and DUMP @, inactive connections after REACTIVATE CONNECTION, archived Scripts after LIB RESTORE, API IDs after SHOW API ENVIRONMENTS, endpoints after SHOW ENDPOINT, and file and folder paths after @, LOAD, IMPORT API BRUNO and inside <@...>.
How you see it: pressing TAB at those positions completes the name or opens a menu.
Syntax or setting: TAB, with activatejline=ON.
How to verify: connected to a database, type SHOW PK and a first letter, then TAB; then type a schema, a dot and a letter, then TAB.
More: TAB completion

Exploring a database

Foreign keys, references and indexes on any database

What changed: new commands show the foreign keys, incoming references and indexes of a table, and find foreign keys and indexes by part of their name, on any JDBC database.
How you see it: bordered tables; an empty result is reported in words, and a missing table is an error.
Syntax or setting: SHOW FK <table>;, SHOW REFERENCES <table>;, SHOW INDEXES <table>;, FIND FK <text>;, FIND INDEX <text>;
How to verify: SHOW FK <a table with a foreign key>; lists each key column and what it references.
More: Exploring a database

`DESCR` lists columns in table order, with precision and scale

What changed: DESCR lists the columns in the order of the table, no longer alphabetically, and its Size column shows precision,scale for DECIMAL and NUMERIC columns.
How you see it: for CREATE TABLE T (Z INTEGER, A VARCHAR(20), M DECIMAL(10,2)), DESCR T; lists Z, A, M, and the sizes of A and M are 20 and 10,2.
Syntax or setting: DESCR <table>;
How to verify: create the table above and run DESCR T;.
More: DESCR, Exploring a database

Table names are resolved exactly, the same way in every command

What changed: DESCR, SHOW PK, SHOW FK, SHOW REFERENCES and SHOW INDEXES find a table the same way: exactly the name typed (tried as typed, then in upper case, then in lower case), in the current schema unless the name is qualified with its schema. _ and % are ordinary characters of the name, never wildcards. SHOW PK country found no table while SHOW FK country did, and DESCR TRY printed an empty table when only COUNTRY existed.
How you see it: a table that does not exist is an error, Table name 'TRY' does not exist, in every one of these commands and in DUMP <table>; a name found in several schemas asks for the schema; a table without a primary key is reported in words by SHOW PK.
Syntax or setting: DESCR <table>;, SHOW PK <table>;, SHOW FK <table>;, SHOW REFERENCES <table>;, SHOW INDEXES <table>;, each with <schema>.<table> too.
How to verify: connected to WORLD, SHOW PK country; lists CODE, and DESCR TRY; reports that the table does not exist.
More: DESCR, SHOW PK, Exploring a database

`ALL`, `CNT`, `DUMP` and `PULL` read exactly the table you name

What changed: these commands found the table you named, then ran their query with the name as typed and without quotes, so the database could read another table: DUMP "Customer" exported CUSTOMER, and ALL "Sales Data" read the table SALES. They now read exactly the table found, with its name quoted for the connected database. Names with spaces, mixed case or reserved words (ORDER) work.
How you see it: ALL "Sales Data"; shows the rows of Sales Data. A name that designates no table and is not a plain name (it contains a space, for example) reports Table name '...' does not exist and runs nothing. A plain name that no lookup finds is still sent to the database as typed, so a synonym keeps working.
Syntax or setting: ALL <table>;, CNT <table>;, DUMP <table> [TO ...] [AS ...];; write a name with spaces or other special characters in double quotes: ALL "Sales Data";
How to verify: CREATE TABLE "Sales Data" (ID INT); INSERT INTO "Sales Data" VALUES (1); then CNT "Sales Data"; counts 1 row, and DUMP "Sales Data" TO sales AS CSV; writes that row.
More: ALL, CNT, Export

`SHOW TABLES` lists tables only

What changed: SHOW TABLES listed every object type the database reports: views, synonyms, and on PostgreSQL also indexes, sequences and types. It now lists tables only (ordinary, temporary and system tables). SHOW VIEWS lists the views, and now also the materialized views of databases that have them.
How you see it: a view no longer appears in SHOW TABLES; it appears in SHOW VIEWS. LOAD refuses a view as its target ("is a view, not a table"), and TAB completion no longer offers synonyms, sequences or indexes as table names.
Syntax or setting: SHOW TABLES [[schema.]pattern];, SHOW VIEWS [[schema.]pattern];
How to verify: CREATE TABLE SALES (ID INT); CREATE VIEW V_SALES AS SELECT * FROM SALES; then SHOW TABLES SALES; lists only SALES, and SHOW VIEWS SALES; lists V_SALES.
More: SHOW TABLES, SHOW VIEWS

`LINK TABLE` links from any database into the current H2 database

What changed: LINK TABLE required the connection to link from to be H2, and never checked the current connection, where it runs H2's CREATE LINKED TABLE. The current connection must now be H2, and the connection linked from can be of any type BroadSQL has a driver for. On another current database, the command is refused before anything is sent to it. The password of the linked connection is never shown in an error message.
How you see it: connected to H2, LINK TABLE <connection> <table>; reports Table '<table>' linked from connection '<connection>'., including for an HSQLDB or PostgreSQL connection. Connected to another database, it reports that LINK TABLE needs an H2 current connection.
Syntax or setting: LINK TABLE <connection> <table>;
How to verify: connected to an H2 database, link a table of an HSQLDB connection and run SELECT * FROM <table>;.
More: LINK TABLE

Every alias of a command works

What changed: an alias that extends another alias of the same command was read as the shorter one followed by arguments: DESCRIBE COUNTRY described a table named DESCRIBE, FIND INDEXES and FIND REFERENCES searched for FIND, and JSEV or JS EV evaluated their own name. A command word now only matches as a whole word, the longest one first.
How you see it: every alias listed by HELP <command> gives the same result as the command's name.
Syntax or setting: for example DESCRIBE <table>;, FIND INDEXES <text>;, FIND REFERENCES <text>;, JSEV <code>;
How to verify: DESCRIBE COUNTRY; and DESCR COUNTRY; print the same columns.
More: DESCR, FIND INDEX, FIND FK

`SHOW AUTOCOMMIT` is the command's name

What changed: the command that shows the autocommit mode is named SHOW AUTOCOMMIT; AUTOCOMMIT still works.
How you see it: HELP SHOW AUTOCOMMIT; and the command reference use the new name.
Syntax or setting: SHOW AUTOCOMMIT;
How to verify: both SHOW AUTOCOMMIT; and AUTOCOMMIT; print the current mode.
More: SHOW AUTOCOMMIT

Connections and Environments

`ENV` switches to another Environment

What changed: ENV <environment> connects to the connection of that Environment in the current connection's Database Group. ENVT and CONNECT ENVIRONMENT are aliases.
How you see it: the prompt changes to the other connection, as after CONNECT.
Syntax or setting: ENV QA;
How to verify: connected to the DEV connection of a Database Group that also has QA, type ENV QA;. HELP ENV; shows the command; the Environments category is now HELP ENVS;.
More: ENV

Saving a new connection works again

What changed: saving a new connection failed with "NULL not allowed for column DRIVER", from CONFIG, ADD CONNECTION, DUPLICATE CONNECTION, and DUMP ... AS H2 when it creates its H2 connection. The connection is now saved with the JDBC driver of its type, the one CONFIG shows; editing a connection keeps that driver in step with its type.
How you see it: CONFIG, Save: the connection is created, and its Driver is still shown when you open it again.
Syntax or setting: none.
How to verify: in CONFIG, create a connection of type H2 (Driver org.h2.Driver), save it, close and reopen CONFIG: the connection is listed with its driver.
More: Getting started, CONFIG

Oracle and Derby connections can be saved

What changed: the connections file BroadSQL ships had no driver for the Oracle type, so a new Oracle connection could not be saved ("No JDBC driver class is known for database type 'Oracle'"), and the Derby types named driver classes the included Derby no longer has. The types now use oracle.jdbc.OracleDriver, org.apache.derby.iapi.jdbc.AutoloadedDriver (Derby embedded, included) and org.apache.derby.client.ClientAutoloadedDriver (Derby client). A connection uses its type's driver; a type without one uses the driver saved with the connection, and that driver is kept when BroadSQL restarts.
How you see it: saving an Oracle connection works; CONFIG shows its Driver.
Syntax or setting: none. An existing connections file keeps its own types: run SYNC TYPE CATALOG; to update them.
How to verify: on a fresh installation, ADD CONNECTION ORA; with type Oracle, then SHOW CONNECTION ORA;. Connecting also needs the Oracle driver JAR in the drivers folder.
More: Technical requirements, Getting started

Connection IDs: at most 15 characters, not case-sensitive

What changed: a new connection ID is checked before the first question: longer than 15 characters, or equal to an existing ID in another case (world when WORLD exists, even inactive), it is refused with a clear message instead of a database error at the end. EDIT CONNECTION accepts the ID in any case.
How you see it: Connection 'WORLD' already exists. Connection IDs are case-insensitive. and Connection ID 'ABCDEFGHIJKLMNOP' is 16 characters long: it must not exceed 15 characters.
Syntax or setting: ADD CONNECTION <id>;, DUPLICATE CONNECTION <id> <new id>;, CONFIG
How to verify: ADD CONNECTION world; on a fresh installation.
More: Getting started, ADD CONNECTION

A cancelled or failed edit leaves the connection as it was

What changed: EDIT CONNECTION changed the connection in memory while you answered, so after answering c (cancel), or after a failed save, CONNECT could still use the URL or user you had cancelled until BroadSQL restarted. The edit is now a draft until it is saved.
How you see it: after a cancelled edit, CONNECT <id> uses the saved URL and user.
Syntax or setting: EDIT CONNECTION <id>;
How to verify: EDIT CONNECTION WORLD;, change the URL, answer c, then CONNECT WORLD;.
More: EDIT CONNECTION

Passwords are no longer shown when editing a connection

What changed: EDIT CONNECTION and DUPLICATE CONNECTION printed the current password in clear before asking whether to keep it; it is now shown as ********. In CONFIG, a password retyped differently is now refused (the two fields were never actually compared).
How you see it: "Current value for 'User Password': ********"; in CONFIG, Save or Test with two different passwords reports "Password and repeated password are different".
Syntax or setting: none.
How to verify: EDIT CONNECTION <id>; on a connection with a password; in CONFIG, type two different passwords and click Save.
More: EDIT CONNECTION, CONFIG

A connection cannot refer to an inactive Database Group or Environment

What changed: saving a connection whose Database Group or Environment is inactive is refused.
How you see it: an error names the inactive Database Group or Environment, and the connection is not saved.
Syntax or setting: none.
How to verify: deactivate a Database Group, then try to save a connection that uses it.
More: Getting started

Disconnecting from HSQLDB works with `Autocommit` off

What changed: with Autocommit=false (the default), leaving an HSQLDB connection (DISCONNECT, CONNECT or ENV to another connection, leaving BroadSQL) failed with an error, because BroadSQL asked HSQLDB a question only H2 understands. Leaving any connection now always rolls back pending changes, never commits them, and closes the connection. When a database cannot say whether changes are pending, BroadSQL warns and rolls back.
How you see it: after an uncommitted INSERT on HSQLDB, DISCONNECT; prints Uncommitted transactions aborted. Rolling back. and disconnects.
Syntax or setting: Autocommit in BroadSQL.ini.
How to verify: connected to an HSQLDB database with Autocommit=false, run an INSERT, then DISCONNECT;, reconnect and check that the row is not there.
More: Technical requirements

`EXIT` disconnects once, without a spurious error

What changed: after EXIT, BroadSQL closed the current connection a second time while shutting down. With Autocommit=false this printed Could not determine whether uncommitted changes are pending. Rolling back., an error saying the connection was already closed, and a second Disconnected from line. It happened with every connection, the Connections Definition File included. Leaving BroadSQL now disconnects once; pending changes are still rolled back, never committed.
How you see it: EXIT prints a single Disconnected from '...' line and no warning or error.
Syntax or setting: EXIT
How to verify: start BroadSQL, stay on $CDF (or CONNECT WORLD;), type EXIT: one Disconnected from line. With Autocommit=false, run an uncommitted INSERT first: EXIT prints Uncommitted transactions aborted. Rolling back. once, and the row is not there after restarting.
More: Interactive console

Export

`DUMP` is the one export command

What changed: DUMP exports a table, a query in parentheses, the result on screen (DUMP /, never run again), a Scripts Library script's final result (DUMP LIB <script>) and the last API result (DUMP API RESULT), with an optional TO <name> and AS CSV, TEXT, JSON, XLSX, ODS, H2, MD or HTML. Without AS, the DefaultFileFormat setting applies. PULL remains an alias.
How you see it: a message names the file written.
Syntax or setting: DUMP <source> [TO <destination>] [AS <format>];
How to verify: DUMP (SELECT 1 AS N) TO one AS CSV; writes one.csv in the export folder.
More: Export

`DUMP @<script>`

What changed: DUMP @<script> is the same as DUMP LIB <script>, written the way a script is run at the prompt.
How you see it: the same file and the same messages as DUMP LIB.
Syntax or setting: DUMP @sales.sql;, DUMP @sales.sql TO sales AS CSV;, DUMP @sales.sql TO sales.DATA AS XLSX;, DUMP @"monthly sales.sql";
How to verify: run DUMP @<script> and DUMP LIB <script> with the same TO and AS: the two files are identical, and the result you had on screen before is not exported.
More: Export

Exporting a Script: named arguments, and only after `SUCCESS`

What changed: DUMP LIB and DUMP @ (and PULL) accept the Script's named arguments before TO, and write the file only when the Script ends SUCCESS. A Script that completes with errors, fails or is cancelled exports nothing, and the error states its status.
How you see it: DUMP LIB monthly.bsql not exported: the script finished with status COMPLETED_WITH_ERRORS
Syntax or setting: DUMP LIB monthly.bsql region='EU' TO revenue_eu AS CSV;
How to verify: export a Script that contains one failing statement: no file is written.
More: Exporting a script's result

Variables in an exported query

What changed: the query in parentheses of DUMP and PULL may use ${name} variables, passed to the database as typed values, with MODE APPEND as well.
How you see it: the exported rows match the variable's value.
Syntax or setting: LET m = SELECT MAX(month_id) FROM calendar; DUMP (SELECT * FROM revenue WHERE month_id = ${m}) TO revenue AS XLSX;
How to verify: LET c = 'FR'; DUMP (SELECT * FROM customer WHERE country = ${c}) TO fr AS CSV;
More: Export

CSV uses the `CsvSeparator` setting

What changed: AS CSV uses CsvSeparator (COMMA or SEMICOLON, default SEMICOLON); AS TEXT always uses a tab.
How you see it: the separator in the .csv files written by DUMP.
Syntax or setting: CsvSeparator=COMMA or CsvSeparator=SEMICOLON.
How to verify: set CsvSeparator=COMMA, restart, run a DUMP ... AS CSV and open the file.
More: Application settings

`DUMP <table>` writes through the same writers as the other sources

What changed: a .csv file written by DUMP <table> uses CsvSeparator (it was always a comma), .xlsx and .ods files gain a QUERIES worksheet, and LOB and binary columns are refused.
How you see it: the content of the files written by DUMP <table>.
Syntax or setting: DUMP <table>;
How to verify: DUMP <table> AS XLSX; and open the file: it has a QUERIES worksheet.
More: DUMP <table> alone

Times and timestamps keep their fractional seconds

What changed: CSV, TEXT, JSON, MD and HTML files wrote times and timestamps to the whole second: 2015-05-07 09:49:01.016 became 2015-05-07 09:49:01. The fraction the value carries is now kept, in groups of three digits; a whole second is written without a fraction. XLSX shows the milliseconds of the values that have some.
How you see it: 2015-05-07 09:49:01.016 in the exported file.
Syntax or setting: DUMP <source> AS CSV; (and every other format)
How to verify: DUMP (SELECT TIMESTAMP '2015-05-07 09:49:01.016' AS TS) TO ts AS CSV; and open ts.csv.
More: Export

Time-zone-aware timestamps are exported the same way on every computer

What changed: a TIMESTAMP WITH TIME ZONE value (PostgreSQL timestamptz, Oracle TIMESTAMP WITH [LOCAL] TIME ZONE) was exported without its offset, converted to the time zone of the computer running BroadSQL: the same row gave different files on different computers. The text formats now keep the value's own offset; XLSX and ODS hold a native date/time cell of the same moment in UTC; AS H2 keeps the offset. Time-zone-less DATE, TIME and TIMESTAMP values are never converted.
How you see it: 2024-01-15 10:00:00+05:00 in CSV, TEXT, MD and HTML, "2024-01-15T10:00:00+05:00" in JSON, and a date/time cell showing 2024-01-15 05:00:00 in Excel or Calc, usable at once for sorting, filtering and formulas.
Syntax or setting: DUMP <source> AS <format>;, DUMP / included.
How to verify: DUMP (SELECT TIMESTAMP WITH TIME ZONE '2024-01-15 10:00:00+05:00' AS TS) TO tz AS CSV; and the same AS XLSX: open both files.
More: Time-zone-aware timestamps

`MODE APPEND KEY` keeps the meaning of a condition with `OR`

What changed: the delta filter was appended after the source's WHERE condition without parentheses, so WHERE A = 1 OR B = 2 became A = 1 OR (B = 2 AND <key> > ...) and every later run appended the A = 1 rows again. The filter now applies to the whole condition. A key named by its select-list alias (O.ID AS ORDER_ID, KEY(ORDER_ID)) is filtered on the aliased column, where later runs used to fail.
How you see it: running the same DUMP ... MODE APPEND KEY(...) again with no new source rows appends 0 rows, whatever the condition.
Syntax or setting: DUMP (<query>) TO <connection>.<table> AS H2 MODE APPEND KEY(<column>);
How to verify: run DUMP (SELECT * FROM CITY WHERE COUNTRYCODE = 'FRA' OR COUNTRYCODE = 'BEL') TO WORKCOPY.CITY_FB AS H2 MODE APPEND KEY(ID); twice: the second run reports 0 rows.
More: MODE APPEND KEY

A result with `NaN` or `Infinity` values is displayed

What changed: a value the database can display but not return with its numeric type (NaN, Infinity) made the whole SELECT fail, and pending changes were rolled back. The SELECT is now displayed and pending changes are kept. DUMP / refuses that result with a clear message instead of writing a value of another type.
How you see it: SELECT CAST('NaN' AS DECFLOAT); on H2 shows NaN; DUMP / then names the column and the value and writes nothing.
Syntax or setting: any SELECT; DUMP /.
How to verify: run the SELECT above, then DUMP / TO x AS CSV;.
More: The previous result

`EXPORT` and `SET SEPARATOR` are no longer documented

What changed: both commands still run, so existing scripts keep working, but they are no longer in the help or the command reference. MS Access (.mdb) output is available only through EXPORT.
How you see it: HELP ALL; no longer lists them.
Syntax or setting: use DUMP instead.
How to verify: HELP ALL; shows DUMP and not EXPORT; an existing script using EXPORT still runs.
More: Scripts from earlier releases

Scripts, files and list sources

Accented characters are read correctly

What changed: Scripts and <@file> lists are read as UTF-8, or as Windows-1252 when they are not valid UTF-8, whatever the system settings.
How you see it: accented characters in a Script saved in the Windows ANSI encoding are no longer corrupted.
Syntax or setting: none.
How to verify: save a Script containing é in ANSI, run it with @, and check the inserted value.
More: Scripts & the Scripts Library

`<@...>` list sources are more robust

What changed: a <@ inside a quoted string or a comment is no longer taken as a list source, an unclosed <@ is reported instead of failing with an internal error, spaces around the file name no longer make BroadSQL hang, and Windows paths with single backslashes work in <@file>.
How you see it: the query runs as written, or a clear error message.
Syntax or setting: <@C:\data\codes.txt>
How to verify: SELECT '<@not a list>'; returns the text as written.
More: Patterns & List Sources

TAB completion keeps backslashes and quotes intact

What changed: completing a path no longer drops or doubles backslashes, and completing a name you started with a quote no longer doubles the quote.
How you see it: the completed text is exactly the path or name.
Syntax or setting: none.
How to verify: type @C:\ and press TAB.
More: TAB completion

Script arguments are named; `%1` to `%9` are removed

What changed: a Script receives named arguments, name=value, read in the Script as ${name}. The positional parameters %1 to %9 no longer exist and the limit of nine parameters is gone. A call with unnamed values fails with an explanation, and %1 in a Script is ordinary text.
How you see it: @report.bsql 42 FR is refused with a message showing the name=value form; @report.bsql customer_id=42 country='FR' runs.
Syntax or setting: @report.bsql customer_id=42 country='FR', LIB RUN report.bsql customer_id=42, and in the Script SELECT * FROM customer WHERE customer_id = ${customer_id} AND country = ${country};. A -- @params: customer_id, country line makes both arguments mandatory for every call.
How to verify: save the Script above, run it with and without customer_id=42; without it, the Script is refused before anything runs. LIB LINT lists every %1 to %9 still in the library.
More: From %1..%9 to named arguments

Variables: `LET`, `${name}` and `SHOW SCRIPT VARIABLES`

What changed: variables hold a value assigned with LET from a number, a quoted string, TRUE, FALSE, NULL, another variable, or a query that returns exactly one row and one column. In SQL, ${name} is passed to the database as a typed value, never pasted into the statement. Variables are shared by the prompt and every Script, and survive CONNECT and ENV.
How you see it: LET max_id = SELECT MAX(id) FROM customer; prints max_id = 1873 (INTEGER); a query that returns no row, several rows or several columns is refused and the variable is unchanged.
Syntax or setting: LET name = value;, SELECT ... WHERE id = ${name};, SHOW SCRIPT VARIABLES;
How to verify: LET n = 'O''Brien'; SELECT ${n}; returns O'Brien; SHOW SCRIPT VARIABLES; lists n.
More: Script variables, LET

`ECHO`, `ON ERROR` and `OUTPUT` in Scripts

What changed: ECHO 'message'; prints a message with variable values; ON ERROR STOP; ends a Script at its first failed statement (the default stays CONTINUE); OUTPUT QUIET; hides a Script's routine output (statement echo, row counts, confirmations) but never results, ECHO, warnings or errors.
How you see it: after ON ERROR STOP;, a failure prints which statement and line stopped the Script, and nothing after it runs, not even a COMMIT.
Syntax or setting: ECHO 'Customer ${customer_id}';, ON ERROR STOP;, ON ERROR CONTINUE;, OUTPUT QUIET;, OUTPUT NORMAL;. ON ERROR and OUTPUT are refused at the prompt.
How to verify: run a Script containing ON ERROR STOP;, a failing INSERT INTO nope VALUES (1); and an ECHO 'after';: after is not printed.
More: Printing messages, Controlling output, Error handling

A Script ends with a status line, and CTRL+C cancels the whole Script

What changed: a Script started at the prompt, from the Editor or by DUMP LIB ends with one line giving its status (SUCCESS, COMPLETED_WITH_ERRORS, FAILED or CANCELLED), the statements run and failed, and a run identifier also written in the application log. CTRL+C now cancels the whole Script, including the Scripts it called, instead of only the current statement.
How you see it: load.bsql: COMPLETED_WITH_ERRORS (4 statements, 1 failed) [run 4M8T0QW2]. On a typed line, a Script whose status is not SUCCESS stops the rest of the line.
Syntax or setting: none.
How to verify: run a Script with one failing statement and read its last line.
More: Run status and Run ID, Cancelling a Script

Rolled back changes are reported

What changed: with Autocommit off, when a failing SQL statement makes BroadSQL roll back changes not yet committed (as it always did), a warning now says so. A Script that ends with uncommitted changes is followed by a notice.
How you see it: WARNING: Pending changes since the last COMMIT on SALES_QA were rolled back.
Syntax or setting: Autocommit=false (the shipped default).
How to verify: with autocommit off, run INSERT INTO t VALUES (1); then a failing statement: the warning follows the error, and the row is gone.
More: Continuing is not keeping the transaction

`ECHO`, `LET`, `ON ERROR`, `OUTPUT` and `SHOW SCRIPT VARIABLES` are BroadSQL commands

What changed: a statement starting with one of these words is run by BroadSQL instead of being sent to the database. No supported database starts a statement with them; MySQL's SHOW VARIABLES is still sent to the database. Multi-word command names now accept several spaces between their words.
How you see it: ECHO 'x'; prints x instead of a database syntax error.
Syntax or setting: none.
How to verify: ECHO 'hello';
More: Command reference

BroadSQL Editor

Run asks for the arguments declared by `@params`, and shows the status

What changed: Run's parameter dialog now shows one field per name of the Script's -- @params: line, in order, and passes them as named arguments; a Script without @params runs without a dialog. The status bar gives the Script's status, and the Metadata tab shows the declared parameters.
How you see it: Run is disabled until every field holds a number, a quoted string, TRUE, FALSE, NULL or one ${variable}.
Syntax or setting: -- @params: customer_id, country in the Script.
How to verify: add that line to a Script, press F5, fill 42 and 'FR'.
More: BroadSQL Editor

What changed: the Editor shows the Scripts pane on the left, the editor in the middle over the whole height of the window, and the Metadata and Output tabs on the right. The text buttons are replaced by a toolbar of icons, and the button row under the tree is gone.
How you see it: the toolbar holds New, New Folder, Save, then Format, Run, History, then Rename, Duplicate, Delete; hovering a button shows its name and shortcut. The Metadata tab lists each label above its field, with a larger Description and two read only values, Path and Last modified.
Syntax or setting: EDIT or LIB EDIT.
How to verify: open a Script with EDIT reports/QR13.sql (any Script of your library): the status bar says Opened 'reports/QR13.sql'. and the Metadata tab shows that path and the file's modification time. Enlarge the window: the editor gets the extra width.
More: BroadSQL Editor

The Scripts pane: sorted tree, icons, drag and drop

What changed: the pane is titled Scripts and shows the library's folders and Scripts directly, folders first, then Scripts, each alphabetically. Scripts and folders, one or several (Ctrl+click, Shift+click), can be dragged onto another folder to move them. The tree always selects the Script of the active tab. A right click acts on the item under the pointer and offers its actions, New Folder and Refresh included. New Folder creates in the selected folder, or beside the selected Script, or at the top when nothing is selected, wherever you start it.
How you see it: folder and Script icons; Enter or a double click opens a Script. A moved Script keeps its history, and its open tab, unsaved changes included, follows it to the new path. The whole move is checked first: an item with the same name at the destination is never overwritten, and nothing moves. Renaming a folder no longer requires closing its open Scripts, and its Scripts keep their history.
Syntax or setting: drag and drop in the Scripts pane.
How to verify: open a Script, type a change, drag it with another Script onto a folder: the tab and the Metadata Path show the new path; Save writes the file there and the old location stays empty. Click another tab: the tree selects that tab's Script.
More: Moving Scripts and folders

Closing several tabs at once

What changed: right clicking an editor tab offers Close, Close Other Tabs, Close Tabs to the Right, Close Tabs to the Left and Close All Tabs.
How you see it: each entry acts relative to the tab you right clicked. Every tab with unsaved changes still asks Save, Discard or Cancel.
Syntax or setting: right click on a tab.
How to verify: open four Scripts, change one, right click the first tab and choose Close Other Tabs: the clean tabs close and the changed one asks first.
More: Editing

Copy a Script's path, or send it to the prompt

What changed: a Script's path can be copied as its library path, its full path on disk, or the command that runs it, and Send to CLI writes that command on the BroadSQL prompt without running it.
How you see it: after Send to CLI, the console prompt shows @reports/QR13.sql;; nothing runs until you press Enter there. A prompt that already holds text, or an unfinished statement, is never changed.
Syntax or setting: Run > Send to CLI; Edit > Copy Library Path, Copy Full Path, Copy CLI Command; the tab and Scripts pane right click menus; the copy button next to Path in the Metadata tab.
How to verify: from the console, run EDIT, open a Script, choose Run > Send to CLI, switch to the console: the command is on the prompt; press Enter to run it.
More: Copy Path and Send to CLI

`EDIT` opens on a new Script ready to type in

What changed: New Script opens a new, unsaved tab instead of asking for a name first; its first Save asks for the name. EDIT and LIB EDIT without a name open the Editor on such a new Script, so the editor is never empty.
How you see it: the tab is titled New Script 1, starts with -- @status: draft, and closes without a question if you did not change it. EDIT <script> opens only that Script and selects it in the tree.
Syntax or setting: EDIT;, LIB EDIT;, New Script.
How to verify: run EDIT;, type a statement, press Ctrl+S: the name dialog appears; give a name, and the Script appears in the tree, selected.
More: New, New Folder, Rename, Duplicate, Delete

Database Group and Environment are chosen from a list in the Metadata tab

What changed: in the Metadata tab of the BroadSQL Editor, Instance (Database Group) and Environment are no longer free text. Each opens a searchable list of the Database Groups or Environments defined in your connection definitions, with a check box per value, so a misspelled name can no longer be entered and found only at Save.
How you see it: selected values appear as chips with a remove button. Typing filters the list; Up, Down, Enter and Esc work in it; Backspace removes the last chip. Once Database Groups are selected, the Environment list shows first the Environments in which they have a connection, and the reverse; every other value stays listed below. Scripts are written in the same format as before.
Syntax or setting: the Metadata tab of the BroadSQL Editor (EDIT).
How to verify: open a Script with EDIT, click Instance (Database Group), type part of a group name, press Enter, then Esc: the group appears as a chip and its -- @instance: line in the text. Open Environment: the environments of that group are listed first.
More: Metadata assistance

Metadata edits keep your comments, and Save updates the Metadata tab

What changed: editing a field of the Metadata tab changes only that metadata line of the Script. Before, it rewrote the comment header: the edited line moved below the blank lines, and comments typed in the header after opening the Script could be lost. Metadata typed directly in the editor now shows in the Metadata tab when you save.
How you see it: comments, block comments, blank lines and the order of the metadata lines stay exactly as you wrote them.
Syntax or setting: the Metadata tab of the BroadSQL Editor.
How to verify: in a Script with comments between its metadata lines, change Tags in the Metadata tab and save: only the @tags line changed. Then change @status in the editor and save: the Status field follows.
More: Metadata assistance

Run from the Editor shows errors in Output, and stays available

What changed: Run no longer fails with an internal error when the activity log is on (IsLogActivated=true), and the Output tab shows plain text, never color codes. Run is available for any open Script, with or without unsaved changes, and is available again after every run.
How you see it: a failing statement shows the database's error in Output, and the status bar says Execution completed with errors: see Output. Run uses the console's current connection, as before.
Syntax or setting: Run (F5) in the BroadSQL Editor.
How to verify: connect, open a Script containing invalid SQL, press F5: Output shows the SQL error with its SQLState; press F5 again: it runs again.
More: Run

Validate and Save with Comment are removed from the Editor

What changed: the Validate command and the Validation tab are removed: they did not check SQL syntax, so a Script reported as valid could still fail. Save with Comment is removed too, its comment was not shown in History. Refresh moved from the toolbar and the View menu to the Scripts pane's right click menu.
How you see it: the right hand pane has Metadata and Output only; File has Save and Save All; there is no View menu. Save still records every revision in History.
Syntax or setting: none. LIB LINT still checks saved Scripts for unknown Database Groups or environments and %N gaps; Save still checks the metadata.
How to verify: open the Editor: no Validate button, no Validation tab, no Save with Comment.
More: BroadSQL Editor

Settings and startup

A missing or invalid setting no longer stops BroadSQL

What changed: when a setting of BroadSQL.ini is missing or invalid, BroadSQL starts anyway.
How you see it: a one-time message at startup names the setting and the default used.
Syntax or setting: any setting of BroadSQL.ini.
How to verify: set displaymode=XYZ, start BroadSQL, and read the startup message.
More: Application settings

New settings `color`, `theme` and `displaymode`

What changed: three new settings. An existing BroadSQL.ini without them gets the defaults (AUTO, default-dark, AUTO) and a startup message.
How you see it: colors and the adaptive table layout are on after upgrading.
Syntax or setting: theme=none keeps the previous appearance.
How to verify: start BroadSQL with an .ini from 5.3.0 and read the startup message.
More: Application settings

Official configuration files cleaned up

What changed: the Linux broadsqlux.ini no longer contains ServersFileType, TemporaryFolder and prompt.text, which BroadSQL did not read, and now lists activatejline, jlinehistoryfile and the apiproxy settings like the Windows file. Both files show scripthistoryvault as a commented example, and the Linux MaxRowsOnScreen is 100, as on Windows (it was 500).
How you see it: the files shipped in conf/.
Syntax or setting: none; existing files keep working.
How to verify: open conf/broadsqlux.ini from the new release.
More: Application settings

Installation and packaging

The launchers work from any folder

What changed: BroadSQL.bat, connect.bat, BroadSQL.ps1 and broadsql.sh start BroadSQL from the installation folder, whatever the current folder. BroadSQL.ps1 now passes its argument on.
How you see it: starting C:\BroadSQL\connect.bat from another folder works, and relative paths (conf/, lib/, samples/) are those of the installation.
Syntax or setting: none.
How to verify: from another folder, run the launcher with its full path and CONNECT WORLD;.
More: Installation

The Linux launcher starts BroadSQL without editing it

What changed: broadsql.sh could not start BroadSQL: it pointed at a Java 8 folder and used the Windows classpath form. It now uses Java 21 or later from JAVA_HOME, or else from the PATH, refuses an older Java, and is executable once unzipped. The Linux settings now write the activity log to the installation's logs folder. The Windows .bat files are always shipped with Windows line endings.
How you see it: ./broadsql.sh starts BroadSQL, from the installation folder or through its full path from any folder; ./broadsql.sh WORLD opens WORLD.
Syntax or setting: ./broadsql.sh [connection]
How to verify: on Linux with Java 21, unzip the release, run /path/to/broadsql.sh WORLD from another folder, log in, and run SHOW TABLES;.
More: Installation

Aligned banners in the shipped files

What changed: the BroadSQL banner at the top of the launchers, the INI files, README.txt and the log configuration is framed to its longest line, whatever the release number, and the log configuration shows the current release instead of 4.6.
How you see it: the right-hand | of every banner line is aligned.
Syntax or setting: none.
How to verify: open conf/BroadSQL.ini and BroadSQL.bat: the banner borders line up.
More: Installation

Extensions

Extensions are loaded on Linux too

What changed: the Linux settings left CustomExtensionsFolder empty, so the commands of an extension JAR were not registered on Linux although the JAR was on the classpath. Both platforms now read the installation's extensions folder.
How you see it: the extension's commands are listed by HELP EXT; on Linux.
Syntax or setting: CustomExtensionsFolder=extensions
How to verify: on Linux, copy an extension JAR into extensions, start BroadSQL and run its command.
More: Extending BroadSQL

`SHOW EXTENSION ERRORS`

What changed: a new command lists the extension and command loading failures recorded at startup. An extension command whose keyword conflicts with an existing command is rejected and listed there.
How you see it: one line per failure, or No extension errors.
Syntax or setting: SHOW EXTENSION ERRORS;
How to verify: type SHOW EXTENSION ERRORS; after startup.
More: Extending BroadSQL