BroadSQL BroadSQL Downloads
Articles / A nicer place to work: what BroadSQL 5.4.0 and 5.4.5 bring you

A nicer place to work: what BroadSQL 5.4.0 and 5.4.5 bring you

October 8, 2026

#release #console #scripting #monitoring #export

A console with colors, themes and tables that fit your window. A Scripts workflow with real variables, named arguments and a much friendlier Editor. A new REPEAT command that keeps an eye on your data while you do something else. And one simple export command, DUMP, that now does everything. Here is the story of BroadSQL 5.4.0 and 5.4.5, and why we think you'll enjoy them.

If you use BroadSQL a lot, you probably spend more time in it than you'd care to admit. You open it in the morning to check that last night's jobs ran. You keep it open during an incident, bouncing between environments. You use it to pull a quick export for someone who asked for "just a spreadsheet" five minutes before a meeting. It's a tool you live in, not one you visit.

That's the thread running through these two releases. BroadSQL 5.4.0, published on October 2, 2026, was a big one. BroadSQL 5.4.5 followed on October 8 with a brand new command, welcome additions to export, and a round of polish. Together, they don't add one headline feature so much as make the whole day feel better.

This article walks through them in roughly the order you'd notice them, starting with the screen you look at all day. The release notes for 5.4.0 and 5.4.5 list every change; think of this as the guided tour.

The console grows up

For a long time, BroadSQL's console was honest but plain: everything came out in the same color as everything else. That works, but it's tiring when you're scanning a long session for the one error that matters. In 5.4.0, the console got a proper makeover, and it's the first thing you'll notice.

Color that actually helps

As you type, BroadSQL now highlights what you write: SQL keywords, strings and numbers, comments, and BroadSQL's own commands with their arguments each get their own style. It sounds cosmetic until you've used it for a day. An unclosed string jumps out because everything after it turns the wrong color, and a long WHERE clause becomes something you can read at a glance instead of decode.

Messages got the same treatment. Errors, warnings, information messages and "it worked" confirmations each have their own color, so the difference between "3 row(s) updated" and an error from the database no longer depends on you reading every line carefully.

And then there's the prompt. The prompt is colored too, and here's the part we're especially happy with: when the current connection's Environment is flagged as Production, the prompt gets a distinct style. If you've ever typed an UPDATE and then had that cold moment of "wait, which database am I on?", you'll appreciate this one. The prompt already told you the connection name; now it tells you, in a way that's hard to miss, when you're somewhere that deserves extra care. It's a small thing that quietly reduces the chance of a very bad afternoon.

Highlighting is purely for reading. What runs is exactly what you typed, and vendor-specific SQL that BroadSQL doesn't recognize is simply left uncolored rather than guessed at. Colors never end up in your exports or in the activity log either.

Pick a theme that suits your terminal

Terminals vary a lot, so instead of one fixed color scheme, 5.4.0 comes with themes, chosen with the theme setting in BroadSQL.ini: default-dark (the default) and default-light, a classic theme with traditional red, yellow and green messages, high-contrast-dark and high-contrast-light for when readability matters more than subtlety, and mono, which uses only bold, underline and inverse.

A companion setting, color, decides whether colors are used at all. Its default, AUTO, turns them on only when the terminal supports them, and never when the output is redirected to a file or a pipe, so scripts that capture BroadSQL's output keep getting clean text.

If you liked things the way they were, that's completely fine: theme=none brings back the previous appearance exactly. And if your existing BroadSQL.ini doesn't have these new settings yet, BroadSQL simply uses the defaults and tells you once, at startup. More generally, a missing or invalid setting no longer stops BroadSQL from starting: you get a one-time message naming the setting and the default used.

Tables that fit your window

Query results used to come out at whatever width the columns asked for. On a laptop, or in a terminal squeezed next to your editor, a table with a couple of long text columns would wrap into an unreadable mess.

Result tables now follow the width of your terminal window. With the default displaymode=AUTO, BroadSQL looks at the actual width before printing each table. In a typical window, you get the familiar layout where every column is as wide as it needs to be. In a narrow window, BroadSQL switches to a compact layout: the widest columns are narrowed and long values are shortened on screen, marked with a ~ so you know there's more. If the table really can't fit, each row is shown vertically, one COLUMN: value line per column, which is often exactly what you want for a single wide record anyway. On a very wide screen, you get a little extra breathing room between columns.

Because the width is checked before each table, resizing the window just works: make it bigger, run the query again, and the next result uses the space. And here's the important bit: the shortening is display only. When you export the result you're looking at, or reuse it elsewhere in BroadSQL, you always get the full values. The screen adapts to you; your data stays intact.

While we were at it, every table BroadSQL prints now has the same bordered shape, whether it's your query result or the output of SHOW TABLES.

Less typing, fewer typos

TAB completion was already useful in 5.3.0, where it learned the names of your connections, environments and Scripts. In 5.4.0 it reaches a lot further. It completes table names after DESCR, DUMP, SHOW PK, ALL, CNT and more. It understands schemas, so typing sales.o and pressing TAB offers the tables of the sales schema that start with o. It completes file and folder paths after @, LOAD and inside list sources such as <@file>. It even knows which connections are inactive when you type REACTIVATE CONNECTION, and which Scripts are archived when you type LIB RESTORE.

If you've ever mistyped a long table name three times in a row during an incident, you know exactly how much that's worth.

In 5.4.5, TAB also got more polite. When you paste or indent SQL, a TAB character stays a TAB instead of triggering completion in the middle of your query, and after a space TAB shows the candidates without inserting anything you didn't ask for. Pasting a query from your editor now feels natural rather than risky.

A few keyboard shortcuts round this out. Esc now cancels the whole statement you're typing, including the earlier lines of a multi-line query you haven't finished yet. That's the "never mind" key you always wanted. Ctrl+U deletes from the cursor back to the start of the line. And HELP SHORTCUTS; lists them all, as does the new Interactive console page.

Ctrl+C that behaves

Speaking of keys, Ctrl+C deserves its own paragraph. Everyone has started a query that turned out to be much slower than expected. You press Ctrl+C and hope. In 5.4.5, Ctrl+C during a running query, a running Script or a REPEAT stops only that piece of work and leaves you at the prompt, still connected, ready for the next thing. A Ctrl+C pressed just as a query is being sent is no longer missed, and reruns on another environment with / <environment> can be cancelled too.

BroadSQL can only ask the database to stop a statement, and some databases stop faster than others. But the part BroadSQL controls is now dependable: you won't lose your session because you changed your mind about a query.

A few more things that make exploring nicer

A handful of smaller additions make finding your way around a database more comfortable. SHOW FK, SHOW REFERENCES and SHOW INDEXES show the foreign keys, incoming references and indexes of a table on any JDBC database, and FIND FK and FIND INDEX find them by part of their name. DESCR now lists columns in their table order and shows precision and scale for DECIMAL and NUMERIC columns, and in 5.4.5 you can add ALPHA to get them sorted by name instead, which is handy when you're hunting for one column in a table with eighty of them:

DESCR CUSTOMER ALPHA;

If you organize your connections into Database Groups and Environments, the new ENV command hops between them by name: connected to your billing system's development database, ENV QA; takes you to the QA connection of the same Database Group.

And to try all of this without setting up a single connection, BroadSQL now ships with a sample database called WORLD: countries, cities, languages, currencies and regions. On a fresh installation, CONNECT WORLD; just works, and it makes a nice playground:

CONNECT WORLD;
SHOW TABLES;
DESCR COUNTRY;
SELECT CODE, NAME, CONTINENT FROM COUNTRY WHERE CONTINENT = 'Europe';
SHOW REFERENCES COUNTRY;

Scripts you can actually build on

A lot of the real value of a tool like this shows up the second time you do something: the Monday health check, the investigation queries you dig out for a certain kind of ticket, the month-end extract. That's what Scripts and the Scripts Library are for, and 5.4.0 made them a lot more capable, and more comfortable to write.

The BroadSQL Editor, reorganized

The BroadSQL Editor is the window where you browse, write, run and version the Scripts in your Scripts Library. You open it with EDIT or LIB EDIT. In 5.4.0 it was substantially reworked, and it now feels much more like the editors you're used to.

The window is organized into three panes: your Scripts on the left, the editor in the middle, and on the right, tabs for the Script's Metadata and for its Output when you run it. An icon toolbar puts the common actions (New, Save, Format, Run, History, Rename, Duplicate, Delete) one click away. The Scripts tree lists folders first and follows you: switch tabs and the tree selects that Script.

Creating a Script is now as simple as it should be. New Script opens an unsaved tab you can start typing in right away; you're asked for a name only when you first save it. Typing EDIT on its own at the prompt does the same. No more deciding on a file name before you even know what the Script is going to do.

Reorganizing is easier too. You can drag Scripts and folders around the tree, several at a time; BroadSQL checks the whole move before anything happens, never overwrites a Script, and keeps each moved Script's revision history. If it's open in a tab, the tab follows it, unsaved changes included.

The Metadata tab got some love as well. Each Script can declare which Database Groups and Environments it's meant for, and those are now chosen from a searchable list of the values you've actually defined, shown as chips, with the compatible values listed first. No more typos in an environment name that only surface later. And when you edit metadata in the tab, only that metadata line changes in the Script's text: your comments, blank lines and ordering stay exactly as you wrote them.

Finally, Send to CLI writes the command that runs the Script straight onto the BroadSQL prompt, ready for you to press Enter (or adjust first). It's a smooth way to go from "I've just written this" to "let me run it against the real thing."

Variables, at last

The biggest change to Scripts in 5.4.0 isn't in the Editor, though. It's in the language. BroadSQL now has proper variables.

You create one with LET, and you use it in SQL as ${name}. A variable can hold a literal value, a copy of another variable, or the result of a query that returns exactly one row and one column:

LET country = 'FR';
LET max_id = SELECT MAX(ID) FROM CUSTOMER;

SELECT ID, NAME FROM CUSTOMER
WHERE COUNTRY = ${country} AND ID <= ${max_id};

There's one design choice here that's worth understanding, because it makes variables both safer and easier to use than you might expect. BroadSQL never pastes the value of ${name} into the text of your SQL. Instead, it sends the statement to the database with a placeholder and hands the value over separately, with its type. In database terms, it's a bound parameter.

What that means for you, in practice:

The flip side is that a variable stands for a value only, not a table or column name. Variables aren't a way to build SQL text on the fly, and that's deliberate.

Variables aren't limited to Scripts, either. They belong to your BroadSQL session, so you can use them at the prompt, and they survive CONNECT and ENV. That opens up a really handy pattern: read a value on one database and use it on another.

LET last_order = SELECT MAX(ID) FROM ORDERS;
ENV QA;
SELECT COUNT(*) FROM ORDERS WHERE ID > ${last_order};

Three lines, and you know how QA compares with the environment you started on, without copying a number by hand and hoping you didn't fat-finger it. When you lose track of what you've defined, SHOW SCRIPT VARIABLES; lists every variable with its type and value.

Named arguments, and goodbye to %1

Variables also changed how you pass values into a Script. Instead of positional parameters, Scripts now take named arguments:

@customer-report.sql country='FR' min_id=100
LIB RUN customer-report.sql country='FR' min_id=100

Inside the Script, those arguments are simply variables. A Script can also declare which arguments it requires, with a metadata line:

-- @params: country, min_id
SELECT ID, NAME FROM CUSTOMER
WHERE COUNTRY = ${country} AND ID >= ${min_id};

If someone runs it without one of them, BroadSQL refuses before running anything and tells them which argument is missing. That's a big improvement over a Script that runs halfway and then fails on an undefined value. It also makes Scripts more self-documenting: six months from now, country='FR' min_id=100 tells you a lot more than FR 100 ever did. And there's no longer a limit of nine parameters.

The BroadSQL Editor knows about @params too. When you click Run on a Script that declares arguments, the Editor asks you for each value, then shows you the Script's final status when it's done.

This is the one place in these releases where you need to check your existing Scripts. The old positional parameters, %1 to %9, are gone. A Script called the old way fails with a message explaining how to migrate, and inside a Script, %1 is now just ordinary text. LIB LINT reports every leftover %1 to %9 in your library, so finding them takes one command. The conversion itself is usually quick: name your arguments, replace '%2' with ${country} (no quotes, since it's a typed value now), and add an @params line. The Arguments and parameters page shows a before-and-after.

Scripts that tell you what happened

The other half of making Scripts practical is knowing what they did. 5.4.0 adds a few simple commands for that.

ECHO prints a message, and it can include variable values. OUTPUT QUIET hides the routine chatter (statement echoes, row counts, LET confirmations) from that point on, while still showing result tables, your ECHO messages, warnings and errors. ON ERROR STOP ends a Script at its first failure; ON ERROR CONTINUE, the default, reports the failure and moves on.

And every Script run now ends with a status line: SUCCESS, COMPLETED_WITH_ERRORS, FAILED or CANCELLED, along with the number of statements, the number that failed, and a run identifier. A quiet Script that succeeds stays quiet; a quiet Script that goes wrong still tells you so.

Put together, a Monday morning check might look like this:

-- @description: Weekly order health check
-- @params: region
ON ERROR STOP;
OUTPUT QUIET;
LET open_orders = SELECT COUNT(*) FROM ORDERS WHERE STATUS = 'OPEN' AND REGION = ${region};
LET failed_invoices = SELECT COUNT(*) FROM INVOICES WHERE STATUS = 'FAILED' AND REGION = ${region};
ECHO 'Region ${region}: ${open_orders} open orders, ${failed_invoices} failed invoices';
SELECT STATUS, COUNT(*) AS CNT FROM ORDERS WHERE REGION = ${region} GROUP BY STATUS;

Run it with LIB RUN weekly-check.bsql region='EU', and you get one clear summary line and one small table, not a wall of output. If one of the queries fails, the Script stops right there and the status line says so.

Two more details make Scripts more trustworthy. Ctrl+C now cancels the whole Script run, including any Scripts it called, instead of just the current statement. And BroadSQL is more open about transactions: when a failed statement leads to a rollback that discards changes you hadn't committed yet, you're told, and when a Script ends with uncommitted changes, a notice after the status line reminds you. No more silent surprises about what was or wasn't saved.

If you want to go further, the Variables and Output and error handling pages cover all of this in depth.

REPEAT: let BroadSQL keep watch

Here's a situation you might recognize. A batch job got stuck overnight and someone restarted it. Is the queue actually going down? So you run a count, wait, press the up arrow and Enter, wait, do it again. Ten minutes later you're still at it, and you've lost track of what the number was three runs ago.

BroadSQL 5.4.5 introduces REPEAT, and it's built for exactly this. In its simplest form, it runs your last query again and again:

SELECT COUNT(*) FROM JOBS WHERE STATUS = 'RUNNING';
REPEAT EVERY 5s;

That's it. BroadSQL runs the count, waits five seconds, runs it again, and keeps going until you press Ctrl+C. Each iteration starts with a header line giving its number and time, like === Repeat #3 at 2026-10-07 21:10:13 ===, and the results follow underneath, so you can scroll back and see the whole story. The screen is never cleared, which is exactly what you want when you're trying to spot a trend.

The wait is measured from the end of one iteration to the start of the next, so iterations never overlap. If your query takes three seconds and you asked for EVERY 10s, a new run starts about every thirteen seconds. Your database never gets two copies of the same monitoring query fighting each other because one ran slow.

Watching several things at once

Real monitoring rarely involves just one number. When a deployment goes out, you might want to keep an eye on new orders, new invoices and failed payments at the same time. REPEAT accepts a block of queries between BEGIN and END:

REPEAT
BEGIN
    SELECT COUNT(*) FROM ORDERS;
    SELECT COUNT(*) FROM INVOICES;
    SELECT COUNT(*) FROM PAYMENTS WHERE STATUS = 'FAILED';
END
EVERY 10s;

Every ten seconds, BroadSQL runs the three queries in order and shows each result labeled with its position and query, so you always know which number is which. You can type a block like this over several lines at the prompt: the semicolons inside the block don't run it, the final EVERY ...; does.

And if you watch the same things regularly, you don't have to retype them. REPEAT works with Scripts, so you can keep your favorite monitoring queries in the Scripts Library and point REPEAT at them:

REPEAT LIB RUN monitor.sql EVERY 10s FOR 30m;

This is where the Scripts improvements and REPEAT really click together. You write the monitoring Script once, in the Editor, give it a description and the right Environment metadata, and from then on it's one short command whenever there's something to watch. You can pass named arguments, too, so the same Script can watch whichever region or queue you're interested in today.

Knowing when to stop

Not every watch should run until you remember to stop it. FOR sets how long to keep going, and COUNT sets how many times to run:

REPEAT / EVERY 10s COUNT 6;
REPEAT @monitor.sql EVERY 1m FOR 2h;

The first one checks six times over about a minute, which is perfect for "let me just confirm this settles down." The second one keeps an eye on things for two hours, which is more like "I'm going to work on something else, show me what happened when I come back." Durations are written as a whole number with s, m or h: 10s, 5m, 2h. If you write something BroadSQL doesn't accept, like 1h30m, it explains what to write instead (90m, in that case).

Turning a watch into a record

Here's our favorite part. Add TO and a file name, and REPEAT also records every iteration to a file, while still showing everything on screen:

REPEAT
BEGIN
    SELECT STATUS, COUNT(*) AS CNT FROM PROCESS_QUEUE GROUP BY STATUS;
END
EVERY 10s
FOR 1h
TO queue-monitor.csv AS CSV;

Each iteration is appended to the file, never overwriting what's already there. In CSV and JSON, BroadSQL adds a TIMESTAMP column at the front with the time each iteration started, so the file is a ready-made timeline without you having to change your query at all. Open queue-monitor.csv in a spreadsheet an hour later and you can chart how the queue drained, show it to whoever asked, or attach it to the incident ticket. What used to be "I watched it for an hour and it looked fine" becomes an actual record.

CSV and JSON files hold one table, so they need exactly one result per iteration. If you're watching several queries at once, the TEXT format records them all as a readable log, each iteration with its number, its time and every query's rows.

Queries only, on purpose

A command that runs things repeatedly deserves some guardrails, and REPEAT has a clear one: it repeats queries only. SELECT, WITH, SHOW and EXPLAIN are fine. INSERT, UPDATE, DELETE, DDL and BroadSQL commands such as CONNECT or DUMP are refused, whether they're the last query, part of a block, or inside a Script you asked it to repeat. BroadSQL checks what it can before starting, and checks every statement again just before it runs, so a refused statement never reaches the database.

That doesn't make the database read-only (a query can still call a function that has side effects, and BroadSQL doesn't look inside functions), but it does mean that an accidental REPEAT EVERY 1s after an UPDATE is simply refused, rather than something you discover later. The first error also stops the REPEAT, so a broken query doesn't spam the same error message every ten seconds.

REPEAT runs in the foreground: it keeps the prompt until it's done, and Ctrl+C stops it at any point, even during the wait. It's not a background scheduler. It's the "keep an eye on this for me" command, and you'll reach for it surprisingly often: after a deployment, during a data migration, or when someone asks "is it still stuck?" for the fourth time in an hour.

DUMP: one export command to remember

Getting data into a file is one of the most common things people do with BroadSQL. Over the years, that job had been spread across several commands with slightly different rules: EXPORT, PULL, and an earlier, simpler DUMP. You had to remember which one did what.

In 5.4.0, DUMP became the export command. It has one shape, and you can say it out loud: dump something, optionally TO a name, optionally AS a format.

DUMP CUSTOMER;
DUMP CUSTOMER TO customers AS CSV;
DUMP (SELECT * FROM CUSTOMER WHERE COUNTRY = 'FR') TO customers.DATA AS XLSX;
DUMP LIB sales.sql TO sales AS JSON;

The "something" can be a table, a query in parentheses, a Script from your library (DUMP LIB sales.sql, or DUMP @sales.sql, which is the same thing), or the last API result. The formats cover what people actually ask for: CSV, TEXT, JSON, XLSX, ODS, H2, Markdown and HTML. Leave out AS, and your DefaultFileFormat setting decides. Files land in your export folder. PULL still works as an alias with exactly the same syntax, so nothing you've written with it breaks.

"Export what I'm looking at"

One form deserves a special mention, because it matches how people really work. You run a query, you look at the result, you tweak it, you run it again, and finally it's right. Now you want that result in a file. Just type:

DUMP /;

DUMP / exports the result that's on your screen, exactly as it was displayed, and never runs the query again. That matters more than it sounds: if the data is changing, or the query was expensive, you get precisely what you saw, not a slightly different answer computed thirty seconds later. And remember the compact table layout from earlier? It doesn't affect this at all. The file always gets the full values, even if the screen showed a shortened version. If the display stopped at your row limit, DUMP / tells you so and suggests DUMP (<query>) instead, rather than quietly exporting half a result.

Scripts and variables, all the way through

Because DUMP arrived in the same release as variables and named arguments, they work together nicely. A query in parentheses can use ${name} variables, and DUMP LIB accepts named arguments, just like LIB RUN:

LET c = 'FR';
DUMP (SELECT * FROM CUSTOMER WHERE COUNTRY = ${c}) TO fr AS CSV;

DUMP LIB monthly.bsql region='EU' TO revenue_eu AS CSV;

That second line is a whole report in one command: run the monthly Script for Europe and write its final result to a CSV file. And here's a thoughtful detail: DUMP LIB writes the file only when the Script finishes with SUCCESS. If anything went wrong, no file is written and the error tells you the status. You'll never send someone a spreadsheet built from a Script that failed halfway through.

New in 5.4.5: keep adding to the same file

The newest improvement is one that people with recurring reports will love. In 5.4.5, DUMP ... AS XLSX, AS ODS and AS H2 accept MODE APPEND: instead of replacing the worksheet or table, BroadSQL adds the new rows to it.

Picture a weekly snapshot of order statuses that you keep in a spreadsheet so you can see the trend over the quarter:

DUMP (SELECT CURRENT_DATE AS SNAPSHOT_DATE, STATUS, COUNT(*) AS CNT
      FROM ORDERS GROUP BY STATUS)
TO order_trend.HISTORY AS XLSX MODE APPEND;

Run it every Monday, and the HISTORY worksheet of order_trend.xlsx grows by a few rows each week, with no copying and pasting between files. If the file or the worksheet doesn't exist yet, it's created the first time. The same works with a local H2 table, which is a great way to build up a small history you can query later:

DUMP (SELECT o.ID, c.NAME AS CUSTOMER, o.AMOUNT
      FROM ORDERS o JOIN CUSTOMER c ON c.ID = o.CUSTOMER_ID)
TO WORKCOPY.ORDERS AS H2 MODE APPEND;

Any query can be appended, joins and all. BroadSQL just checks that the destination has the same columns, with the same names, in the same order. If they don't match, nothing is written and the error tells you what's different, so your history never ends up with a mix of incompatible rows.

You might notice that this pairs nicely with REPEAT ... TO, which also appends. The difference is the job each one does: REPEAT is for watching something closely over minutes or hours, while DUMP ... MODE APPEND is for building up a record over days and weeks, in the formats your colleagues already use.

Small things that make exports trustworthy

A few less visible changes make exports more dependable. Time-zone-aware timestamps are now exported the same way on every computer, whatever its local time zone: text formats keep each value's own offset, and spreadsheets get a proper date/time cell. Fractional seconds survive the trip to CSV, TEXT, JSON, Markdown and HTML. The CSV separator now comes from one setting, CsvSeparator, used consistently by every form of DUMP. And in 5.4.5, BroadSQL refuses to use its own Connections Definition File, the database that holds your connection definitions, as an export destination, so an unlucky TO can't write data into it.

If you have older Scripts that use EXPORT, they still run. It's simply no longer documented, and DUMP is the command we recommend going forward.

Stronger underneath

Not everything in a release is something you'll see. Alongside the new features, 5.4.0 and 5.4.5 include a long list of corrections and robustness improvements, the kind of work that rarely makes a headline but makes a tool feel solid.

A few examples give the flavor. Commands such as ALL, CNT, DESCR and DUMP now read exactly the table you named, even when its name has mixed case, spaces or happens to be a reserved word. Accented characters in Scripts saved with older Windows encodings are no longer garbled. Leaving BroadSQL with EXIT is clean, without the occasional confusing warning on the way out. Passwords no longer appear when editing or duplicating a connection. The launchers work from any folder, and the Linux launcher starts BroadSQL without any editing. Extension commands load on Linux too, and if one fails to load, SHOW EXTENSION ERRORS tells you why.

None of these is dramatic on its own. Together, they mean fewer odd moments and more confidence that BroadSQL is doing exactly what you asked. The 5.4.0 and 5.4.5 release notes list them all if you're curious.

Before you upgrade

Most of what's in these releases just works when you install them. Three things are worth a quick look:

5.4.5 itself needs no special steps on top of 5.4.0.

Wrapping up

If you step back, 5.4.0 and 5.4.5 tell a fairly simple story. The console is a nicer place to spend your day: easier to read, quicker to type in, and clearer about where you are. Scripts have grown from saved files of SQL into something you can genuinely build on, with variables, named arguments, readable output and a status you can trust, written in an Editor that stays out of your way. REPEAT takes over the tedious job of watching something change, and can leave you a record of it. And DUMP turns exporting into one command with one shape, now able to grow a report week after week.

Each of these makes a familiar task a little easier. Together, they make BroadSQL a more comfortable tool to live in, which is what we set out to do. We enjoyed building these releases, and we hope you enjoy using them.

If you're new to BroadSQL, the Getting started guide and the WORLD sample database are the quickest way in. If you've been using it for a while, try a theme, write a small Script with LET, and set a REPEAT on something you'd otherwise keep checking by hand. We think you'll like how it feels.