Command activity log

The activity log keeps a plain-text copy of what you did in BroadSQL: every command you typed on a connection and everything it printed, with the time. By default BroadSQL writes one file per session: from the moment the master password is accepted until LOGOUT or EXIT, whatever the connections and Environments you used in between. This page explains how to turn it on, find a past session and read it. It is independent from the internal application log (logs/broadsql_main_<date>.log, meant for diagnosing BroadSQL itself).

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;
• follow a session that went from a QA connection to a Production one, in the order things happened;
• 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.

Before you start

• In conf/BroadSQL.ini (conf/broadsqlux.ini on Linux), IsLogActivated=TRUE. It is FALSE in the Windows file as shipped and TRUE in the Linux one.
• LogFolderName names a folder that exists. logs, the folder next to BroadSQL.bat and broadsql.sh, always does.

[Log]
IsLogActivated=TRUE
LogFolderName=logs
LogFileNamePattern=CONSOLE
LogByConnection=FALSE

Settings are read at startup: restart BroadSQL after changing them (see Application settings).

Logging a session and finding it again

1. Start BroadSQL and type the master password. The session begins, and its file is created in the log folder.
2. Work as usual: connect, query, run Scripts, switch connections.

`` BroadSQL> CONNECT ACME_INT; ACME_INT> SELECT COUNT(*) FROM CUSTOMER; ACME_INT> CONNECT ACME_QA; ACME_QA> LOGOUT; Logged out. Enter the master password to continue. ``

1. LOGOUT (or EXIT) ends the session. The next master password starts a new session, in a new file.
2. To find a session later, type SHOW SESSIONS. It lists the most recent sessions, newest first, with the connections each one opened:

``` BroadSQL> SHOW SESSIONS; Session activity logs in C:\BroadSQL\logs |-------------------|----------------------|------------------------------------|----------------|-----------------------| |Started |Ended |Session ID |Instance ID |Connections | |-------------------|----------------------|------------------------------------|----------------|-----------------------| |2026-10-23 15:49:25|running (this session)|8a21abf9-90a1-4111-b8fb-93c046f31b18|7K3M9P2W5X8R4T6A| | |2026-10-23 15:49:25|15:49:25 (LOGOUT) |c9ae0940-3346-402c-a635-96918efd797a|7K3M9P2W5X8R4T6A|A (LOCAL), SALESQA (QA)| |-------------------|----------------------|------------------------------------|----------------|-----------------------|

... 2 sessions found. Each file is named CONSOLE_SESSION_<yyyyMMdd>_<HHmmss>_<Session ID>.log. ```

1. Open the file of the session with any text editor. SHOW SESSIONS followed by the first characters of a Session ID shows that one session and the full path of its file:

``` BroadSQL> SHOW SESSIONS c9ae0940; Session activity logs in C:\BroadSQL\logs

File: C:\BroadSQL\logs\CONSOLE_SESSION_20261023_154925_c9ae0940-3346-402c-a635-96918efd797a.log Session ID: c9ae0940-3346-402c-a635-96918efd797a Instance ID: 7K3M9P2W5X8R4T6A Started: 2026-10-23 15:49:25 Ended: 15:49:25 (LOGOUT) BroadSQL: 5.5.x Connections: A (LOCAL), SALESQA (QA) ```

Finding sessions by date, Session ID or installation

The file names sort by date and time, so a plain folder listing is already in chronological order. To find the sessions that used a connection, search the files for CONNECTED <connection ID>, for example with findstr /m /c:"CONNECTED ACME_PROD" CONSOLE_SESSION_*.log on Windows or grep -l "CONNECTED ACME_PROD" CONSOLE_SESSION_*.log on Linux.

Reading a session file

A session file starts with a header, then one line per event or command, in the order they happened:

BroadSQL Activity Log
Instance ID : 7K3M9P2W5X8R4T6A
Session ID  : 9c82f174-5419-4b21-b7d9-3ed076d8a234
Started     : 2026-10-23 14:01:23
BroadSQL    : 5.5.x

2026.10.23 14:01:23 SESSION STARTED
2026.10.23 14:02:01 CONNECTED ACME_INT (Environment INT)
2026.10.23 14:03:12 ACME_INT> SELECT COUNT(*) FROM CUSTOMER;
42
2026.10.23 14:05:41 [Run OYS5JHED] ACME_INT> UPDATE ORDERS SET STATUS = 'X' WHERE ID = 7;
2026.10.23 14:10:07 CONNECTED ACME_QA (Environment QA)
2026.10.23 14:29:58 DISCONNECTED ACME_QA
2026.10.23 14:30:00 SESSION ENDED (LOGOUT)

• A dated line holds a command you typed (after the prompt, which names the connection), a message or a session event. The lines that follow without a date are what the command printed, such as the rows of a result.
• Session events: SESSION STARTED, CONNECTED <connection> (Environment <environment>), DISCONNECTED <connection> and SESSION ENDED (<reason>). The reason is LOGOUT, EXIT, authentication expired after inactivity, a new authentication (the master password was asked again, for example after SET MASTER PASSWORD), application terminated (the window was closed or BroadSQL was stopped) or application stopped (BroadSQL stopped on an error).
• A session file without SESSION ENDED belongs to a session that is still running, or to a BroadSQL that stopped without being able to write it (a crash, a computer switched off). BroadSQL never adds an end that did not happen.
• In a Script run, each line carries [Run <Run ID>]. When the Script ends, its status line names the Script, its result, its counts and the same 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.

The file is written in UTF-8.

Sessions, Session IDs and the Instance ID

A session starts each time the master password is accepted: at startup, after LOGOUT, after an inactivity expiry, or when the password is asked again. It continues across any number of CONNECT, DISCONNECT and ENV commands, and ends with LOGOUT, EXIT or the loss of the authentication. Each session has a new Session ID, a standard UUID; two sessions of the same running BroadSQL have two Session IDs and two files. Several BroadSQL windows running at the same time write separate files.

The Instance ID identifies the installation that wrote the file: more exactly, its INI file. It is 16 characters (digits and capital letters, without I, L, O and U), drawn at random. BroadSQL creates it at its first start and adds it to the INI file as InstanceId=..., after saving a dated backup of the file (see Application settings). It never changes afterwards.

The Instance ID identifies an installation, not a person and not a computer. A copied INI file carries the same Instance ID: if you copy an installation to give it to someone else, delete the InstanceId line in the copy while BroadSQL is closed, and the copy gets its own at its next start.

Logging by connection instead

With LogByConnection=TRUE, BroadSQL writes the activity as earlier releases did: one file per connection and per day, 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. Those files have no header and no session events, and roll over to a new dated file past 2,000,000 lines.

Only one of the two layouts is written at a time; the activity is never written twice. Files already written in the other layout stay in the folder, untouched, and log retention handles both. LogByConnection only chooses the files: with IsLogActivated=FALSE, nothing is logged whatever its value.

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.

What is never logged

• CDF maintenance (CONNECT $CDF): nothing of it, its commands, its results or the master password question, in either layout. A session file only shows DISCONNECTED <connection> when maintenance closes the connection.
• Anything typed at the BroadSQL> prompt, without a connection. The session events record the connections.
• What you type at a password prompt.

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>_SESSION_<yyyyMMdd>_<HHmmss>_<Session ID>.log (for example CONSOLE_SESSION_20260601_140123_9c82f174-5419-4b21-b7d9-3ed076d8a234.log), dated by the start of the session, in LogFolderName; - <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.

Both activity layouts are recognized whatever LogByConnection is now. Today's files are never deleted. Nothing else in these folders is touched (a derby.log of an Apache Derby driver, 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.

Limits and troubleshooting

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

Related pages

• SHOW SESSIONS: the list of past sessions.
• Application settings: IsLogActivated, LogFolderName, LogFileNamePattern, LogByConnection, LogRetentionDays, InstanceId.
• Starting, connecting and logging out: when a session starts and ends.
• Security: which files may hold sensitive data.
• Output and error handling: what OUTPUT QUIET hides on screen but keeps in the log.
• Interactive console: the prompt and the console output the log copies.

History

Releases up to 5.5.0 always wrote the activity log per connection and per day, the layout now chosen with LogByConnection=TRUE. An installation upgraded from such a release keeps its existing files, writes session files from its next start, and receives its Instance ID at that start.

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