BroadSQL Download
On this page
Documentation / Command activity log

Command activity log

BroadSQL can keep a plain-text trail of everything that happens in a session: every command you type, and every piece of output it produces (result sets, messages, errors), can be appended to a log file as you work. This is independent from the internal application log (logs/broadsql_main_<date>.log, meant for diagnosing BroadSQL itself): this page is about the per-connection activity log meant for your own records.

What it is for

The console scrolls away; the activity log keeps it. Turn it on when you want to answer, later, "what exactly did I run, on which database, and what did it print?":

  • review an investigation the next day, or attach the exact commands and results to a ticket;
  • find the full error message of a statement that failed in the middle of a long Script;
  • see everything a Script did, including the routine lines OUTPUT QUIET hides on screen.

The log is a copy of the console, written as you work. It holds what was printed on screen, plus the lines OUTPUT QUIET hid there, and nothing else.

One file per connection, per day

Each connection gets its own file, named:

<LogFileNamePattern>_<connection ID>_<yyyyMMdd>.log

For example, with LogFileNamePattern=broadsql, working on the WORLD and DESK connections on 2026-08-26 produces broadsql_WORLD_20260826.log and broadsql_DESK_20260826.log side by side. The connection ID is the one you used with CONNECT. Nothing is logged at the BroadSQL> prompt, nor in CDF maintenance mode (CONNECT $CDF), even when the log is active.

Files are written in the folder set by LogFolderName (see below), and roll over automatically to a new dated file once a file passes 2,000,000 lines: you never need to manage file size by hand.

Each line is timestamped (yyyy.MM.dd HH:mm:ss), followed by either the prompt and the command you typed, or the output BroadSQL printed back.

Turning it on

Nothing is logged by default. Two settings in conf/BroadSQL.ini, under [Log], control it:

[Log]
IsLogActivated=TRUE
LogFolderName=logs
LogFileNamePattern=broadsql
  • IsLogActivated: master switch. FALSE in the Windows BroadSQL.ini, TRUE in the Linux broadsqlux.ini. Set it to TRUE to log every connection (except CDF maintenance mode) from the moment you connect.
  • LogFolderName: where the files are written. This folder must already exist: if it doesn't, the first write fails, BroadSQL prints "Unable to write to log file" and silently turns logging off for the rest of that session (you don't need to re-enable it manually next time you start BroadSQL, since IsLogActivated in the INI is re-read at startup, but that session's activity is lost). The Windows default (C:\BroadSQL\logs) does not exist out of the box; pointing it at logs (the folder next to BroadSQL.bat/broadsql.sh) is a safer choice, since that folder is already part of the standard install layout. The Linux broadsqlux.ini ships with logs.
  • LogFileNamePattern: the prefix used in the file name (default: CONSOLE).

Toggling it mid-session

SET TRACE; flips logging on or off for the current connection only, without touching the INI file or affecting other connections. It's a hidden command (it won't show up in HELP), meant for a quick "log this one investigation" or "stop logging this noisy import" without editing config files. Reconnecting (CONNECT) resets the setting back to whatever IsLogActivated says.

Reading the log to understand what happened

Open the file of the connection and day you are interested in with any text editor, and search it. Each command you typed is on a line of its own, after the prompt, so a search for the prompt (WORLD-QA>) or for a command name lists what you ran; the lines after it are what BroadSQL printed in return, errors included.

When a Script ends, its status line names the Script, its result, its counts and its Run ID:

load.bsql: COMPLETED_WITH_ERRORS (4 statements, 1 failed) [run OYS5JHED]

The Run ID identifies that one Script run, together with every Script it called. The same identifier is written in the application log, so both logs can be matched. What the statuses mean, and how a run is counted, is described in Nested Scripts and run lifecycle.

Log retention

At each start, BroadSQL deletes its own log files that are older than LogRetentionDays days (default 90; 0 keeps every file). When it deletes something, or cannot, it says so once:

INFO: Log retention (90 days): 12 old log files deleted.

A file is deleted only when all these conditions hold:

  • it is directly in one of two folders, never in a sub-folder: - LogFolderName, for the activity log files; - the logs folder of the installation, for BroadSQL's application log files;
  • its name has exactly one of these forms, with a real calendar date: - <LogFileNamePattern>_<yyyyMMdd>.log or <LogFileNamePattern>_<connection>_<yyyyMMdd>.log (for example CONSOLE_20260601.log, CONSOLE_WORLD_20260601.log), in LogFolderName; - broadsql_main_<yyyyMMdd>.log, in the logs folder;
  • the date in its name is more than LogRetentionDays days before today, and the file was last modified more than LogRetentionDays days ago (a BroadSQL that has been running for days still writes to its file, which is kept);
  • it is a regular file: a folder, a link or a shortcut with such a name is never touched.

Today's files are never deleted. Nothing else in these folders is touched (derby.log, H2 trace files, your own files). A file that cannot be deleted, for example because another program holds it, is skipped and counted. For safety, nothing is deleted when LogFileNamePattern is empty, or when a folder is a link, the root of a disk, your home folder or the installation folder itself; an INFO message says so.

An invalid LogRetentionDays (not a whole number from 0 to 3650) deletes nothing until it is corrected, with an INFO message at startup.

What it is not

The activity log is a convenience for your own records, not an audit trail. The files are plain text that anyone with access to the folder can read, change or delete; logging can be turned off in the settings, or for the current connection with SET TRACE;; and CDF maintenance mode is never logged. Use it to remember and to explain, not as proof.

Found something wrong or unclear on this page? , with the page address.