BroadSQL BroadSQL Downloads
On this page
Documentation / Import / Export: Script and API results

Script and API results

Two sources produce their result when DUMP runs: a Script (DUMP LIB, DUMP @) and an API call (DUMP API RESULT, for the last RUN). The destinations are the same as for any other source: Files and spreadsheets and Local H2 datasets.

Exporting a script's result (DUMP LIB, DUMP @)

DUMP LIB <script> runs a Scripts Library script, exactly as LIB RUN would, and exports its final tabular result. Preparation statements before it (temporary tables, inserts) run normally; the results of intermediate queries are not exported, and no result is displayed while the script runs.

DUMP LIB sales.sql;
DUMP LIB sales.sql TO sales AS CSV;
DUMP LIB reports/sales.sql TO sales.DATA AS XLSX;

DUMP @<script> is the same command, written the way a script is run at the prompt (@sales.sql): DUMP @sales.sql is exactly DUMP LIB sales.sql, with the same TO and AS clauses, the same file names and the same messages.

DUMP @sales.sql;
DUMP @sales.sql TO sales AS CSV;
DUMP @"monthly sales.sql" TO monthly.DATA AS XLSX;

For example, with sales.sql:

CREATE LOCAL TEMPORARY TABLE X (CUSTOMER VARCHAR(50), AMOUNT DECIMAL(10,2));
INSERT INTO X SELECT CUSTOMER, AMOUNT FROM ORDERS WHERE ORDER_DATE >= '2026-01-01';
SELECT CUSTOMER, SUM(AMOUNT) AS TOTAL FROM X GROUP BY CUSTOMER;

DUMP LIB sales.sql AS XLSX; writes the grouped totals to sales.xlsx, worksheet DATA.

  • <script> is a path relative to the Scripts Library, as for LIB RUN; quote it if it contains spaces (DUMP LIB "monthly sales.sql", DUMP @"monthly sales.sql"). TAB completes the Scripts Library names after DUMP LIB and after DUMP @.
  • Named arguments follow the script, before TO and AS, exactly as for @ and LIB RUN: DUMP LIB monthly.bsql region='EU' TO revenue_eu AS CSV;. A value without a name is a syntax error.
  • The file is written only when the script's status is SUCCESS. For COMPLETED_WITH_ERRORS, FAILED (including a missing script or argument) or CANCELLED, nothing is written and an error states the status, for example DUMP LIB monthly.bsql not exported: the script finished with status COMPLETED_WITH_ERRORS. Nothing is written either when it produces no tabular result ("Library script 'sales.sql' produced no exportable tabular result").
  • A LET query in the script never becomes the exported result.
  • The export uses only the script's own result: a query you ran earlier in the session is never exported by DUMP LIB or DUMP @, and DUMP / afterwards still refers to that earlier result.
  • Writing the script itself (named arguments, variables, ECHO, ON ERROR, OUTPUT) is explained in the Scripting pages; the Script side of this export, in Exporting Script results.

Example: a Script with an argument, exported to CSV

reports/by-country.bsql:

-- @params: country
SELECT ID, NAME FROM CUSTOMER WHERE COUNTRY = ${country};
DUMP LIB reports/by-country.bsql country='FR' TO by_country_fr AS CSV;
SELECT ID, NAME FROM CUSTOMER WHERE COUNTRY = ${country}
-- country = 'FR'
2 row(s) captured for DUMP LIB.
reports/by-country.bsql: SUCCESS (1 statement, 0 failed) [run 3SPKKL94]
2 row(s) exported to C:\BroadSQL\export\by_country_fr.csv.

Exporting an API execution result

DUMP API RESULT exports the last RUN result (see Working with API results). Every destination above works the same way:

DUMP API RESULT TO WORKCOPY.USERS AS H2;
DUMP API RESULT TO REPORT.USERS AS XLSX;
DUMP API RESULT TO USERS AS CSV;

The rows exported are the columns and rows shown on screen as a table by RUN; every column is text. MODE APPEND is not supported for this source. AS JSON exports the flattened tabular shape, not the original raw API response body.

Example: keep an API result as a table

CONNECT API MYAPI:Development;
RUN /users;
DUMP API RESULT TO WORKCOPY.USERS AS H2;
2 row(s) exported to WORKCOPY.USERS (table dropped and recreated).

How the result is shaped into rows and columns, and when it is cleared, is described in Working with API results.