BroadSQL BroadSQL Downloads
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. The special $CDF connection is never logged, 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) 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 (SALES_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.

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 is never logged. Use it to remember and to explain, not as proof.