Glossary

Terms specific to BroadSQL, in one place. For everything else, see the command reference.

TermMeaning
CDFConnections Definition File: BroadSQL's configuration database, the encrypted H2 database where it stores every connection you define, the Database Groups, Environments, login scripts and API catalog. It is not an ordinary connection. See The configuration database (CDF).
CDF maintenance modeA direct SQL session on the CDF, for diagnosis and repair: CONNECT $CDF; asks for the master password every time, and the prompt shows $CDF [MAINTENANCE]>. See CDF maintenance mode.
CDF schema versionThe version of the CDF's structure, independent of the BroadSQL release number. BroadSQL upgrades an older CDF at startup, after a backup. See CDF schema versions.
$CDFThe reserved name of the CDF. CONNECT $CDF; opens CDF maintenance mode, never an ordinary connection.
BroadSQL>The prompt when BroadSQL is not connected to any database: the normal state after startup and after DISCONNECT. See Starting, connecting and logging out.
RememberLastConnectionThe setting that reopens your last connection at startup and makes DISCONNECT return to the previous connection. See Remembering the last connection.
LOGOUTEnds the authenticated session without leaving BroadSQL: closes every connection and asks for the master password again. LOGOFF is the same command. See LOGOUT.
Master passwordThe password that unlocks the CDF file (clipper8AD by default on a fresh install). Change it with SET MASTER PASSWORD;. Not the same thing as a connection's own USER_PASSWORD.
ConnectionA row in the CDF's CONNECTIONS table: an ID, a JDBC URL, credentials, a type, a Database Group, and an Environment. CONNECT <id>; opens one. See Connections, Database Groups and Environments.
Database GroupWhich product or system a connection belongs to (Wiki1, JIRA, MYSAP, and so on). Lets you keep connections for different products apart once you have more than a handful; a connection can't reuse the same (Database Group, Environment) pair as another. Purely organizational; doesn't change how a connection behaves. Stored in the CDF's INSTANCE table (kept under that name internally) and managed from the "Database Groups" tab of CONFIG. See Getting started.
EnvironmentWhich deployment platform a connection points at (DEV, TI, QA, LIVE, and so on), with its own Production flag and comment. Managed from the "Environments" tab of CONFIG. ENV <environment> switches to it within the current Database Group.
Production confirmationThe question BroadSQL asks before a statement that can modify the database of a connection whose Environment is flagged Production: every time, or once per connected session (ProductionConfirmEveryChange). See Production confirmation.
Type (TYPE_ID)The database vendor a connection uses (H2, PostgreSQL, Oracle, and so on), matched against a row in the CDF's TYPE table, which supplies the JDBC driver class name. See Technical requirements.
DUMPThe export command: writes a table, the previous result, a query or a library script's result to a file (CSV, TEXT, JSON, XLSX, ODS...) or a local H2 table, under one syntax. Not a database backup. See Export.
PULLA compatibility alias of DUMP, kept so existing scripts keep running. See Export.
ExtractionAny operation that writes query results to a file rather than the screen, that is, a DUMP.
ExtensionA command loaded from a JAR in the extensions/ folder, in addition to BroadSQL's own built-in commands. See Extending BroadSQL.
Activity logA per-connection, per-day text file recording every command typed and its output, independent of BroadSQL's own internal application log. See Command activity log.
Application SettingsThe tab of CONFIG (Windows) that shows and edits the settings of the INI file. See Changing settings.
Screen separator vs. CSV separatorTwo independent settings: ScreenSeparator controls the column separator shown on screen; CsvSeparator (COMMA or SEMICOLON) controls the separator of DUMP ... AS CSV. AS TEXT is always tab separated. See Application settings.
ScriptA text file of SQL statements, BroadSQL commands, or both, separated by ;. Its extension does not matter. Run it with @ or LIB RUN. See the Scripting overview.
Scripts LibraryThe folder of reusable Scripts (scripts/ by default, ScriptsLibrary setting), browsed with the LIB commands and the BroadSQL Editor. Since 5.3.0 it also replaces the former SQL Library. See Scripts Library.
SQL scripting vs. JavaScript scriptingSQL scripting is the normal automation of BroadSQL: Scripts with variables, named arguments, ECHO, OUTPUT and ON ERROR, but no loops or conditions. JavaScript scripting (JS RUN, JS EVAL) is the developer capability for general-purpose logic and several connections at once. See JavaScript scripting.
Script variableA named, typed value of the BroadSQL session, set with LET or by a Script argument and used as ${name}. Shared by the prompt and every Script; survives CONNECT and ENV; lost when BroadSQL exits. See Script variables.
Script variable vs. API variableTwo unrelated sets. LET sets Script variables, used in SQL and listed by SHOW SCRIPT VARIABLES. VAR sets API variables, used only by API requests.
Typed binding (bound value)How ${name} reaches the database: as a separate value with its type, never pasted into the SQL text. A string needs no quotes or escaping, and a variable can never be a table or column name. See Script variables.
Scalar query assignmentLET name = SELECT ...: stores the single value of a query that returns exactly one row and one column. The query result is never displayed or exported.
Named Script argumentA name=value written after a Script reference (@report.sql country='FR'). It assigns a Script variable just before the Script starts. It is not a local function parameter: the value stays in the shared namespace after the Script returns. See Named Script arguments.
@param (typed parameter)A Script metadata line declaring one parameter with its type, an optional default and a description: -- @param since DATE = '2026-01-01' "First day". Each argument is converted to its type before the Script starts; a parameter with a default is optional. See Typed parameters.
List parameterA parameter declared LIST OF <type> and passed as ids=(12, 57, 301). Used as IN (${ids}), each element is sent to the database as its own typed value. At most 1000 elements. See List parameters.
@paramsA Script metadata line (-- @params: country, min_id) listing the arguments every call must pass explicitly. An existing session variable does not satisfy it. No types or defaults: use @param for those.
@accessA Script metadata line, read or write, saying whether the Script is meant to change a database. Information only: shown by LIB SHOW, checked by LIB LINT, never enforced when the Script runs.
@dialectA Script metadata line naming the connection types a Script is written for (PostgreSQL, H2), or ANY. A different connection type gives a warning, never a refusal.
Positional Script parameterThe legacy %1 to %9 syntax, removed and replaced by named arguments. A call such as @report.sql 42 FR now fails. See From %1..%9 to named arguments.
ECHOPrints one single-quoted message, with ${name} replaced by variable values. Never hidden by OUTPUT QUIET.
OUTPUT QUIET / OUTPUT NORMALIn a Script, OUTPUT QUIET hides routine output (statement echo, row counts, LET confirmations, a SUCCESS status line) from that statement on, never results, ECHO, warnings or errors. OUTPUT NORMAL, the default, shows everything again. The activity log always keeps everything.
ON ERRORIn a Script, ON ERROR CONTINUE (the default) runs the next statement after a failure; ON ERROR STOP ends the Script at the first failure. Neither keeps a transaction that a SQL error rolled back. See Error handling.
Nested ScriptA Script run by a statement of another Script (@child.bsql). It shares the caller's variables and belongs to the same run, with the same Run ID.
Script statusThe result of a Script run, printed on its last line: SUCCESS, COMPLETED_WITH_ERRORS, FAILED or CANCELLED. See Run status and Run ID.
Run IDThe 8 character identifier of one top-level Script run, shared by every nested Script and written in the status line and the application log. It identifies a run, not a connection.
DUMP LIB (and DUMP @)Runs a library Script and exports its own final tabular result to a file, only when the Script ends SUCCESS. See Exporting a Script's result.
LOADThe import command: inserts the rows of a UTF-8 CSV file into an existing table, after a preview (PREVIEW) and a confirmation or EXECUTE. It never creates a table or updates a row. See Importing data.
API Client (Universal API Client)The experimental part of BroadSQL that calls HTTP APIs: an API is imported from Bruno or defined in CONFIG API, opened with CONNECT API <api>:<environment>, called with RUN, and its result exported with DUMP API RESULT. An API environment is unrelated to a database Environment. See Universal API Client.
Production (Environment flag)Marks an Environment as production. Its only visible effect is a distinct prompt style when colors are on; it blocks nothing. See Connections, Database Groups and Environments.

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