COPY RESULT

Core command

Copies the most recently produced result, SQL query or RUN, whichever ran last, to the system clipboard as tab-separated text, ready to paste into Excel/Calc

Arguments

None.

Examples

SELECT * FROM CUSTOMER;
COPY RESULT;
RUN /api/customer/123;
COPY RESULT;

Notes

COPY RESULT: puts the last result held in memory on the system clipboard as tab-separated text, ready to paste straight into Excel/Calc; see docs/TODO.md ("Spreadsheet integration") and docs/TECHNICAL_CHANGE.md for why this exists (part C of the Excel/list-source quick-wins batch).

There are two possible sources: a SQL lastSQLQuery (the same one / replays and SHOW QUERY displays, not a cached result set, since BroadSQL does not keep one around after a query finishes, so it is re-run here), or the last RUN result (materialized into a real ResultSet via ApiResultMaterializer, the exact same reusable representation PULL API RESULT TO ... already consumes; see that class's own Javadoc). COPY RESULT always consumes whichever of the two actually ran most recently in this session (SPRINT XT02B acceptance correction, item 6), never a hard-coded SQL-first/API-fallback priority. LastCopyableResultHolder resolves this: it is updated at the exact two points a SQL statement or a successful RUN completes, so it always names the true winner regardless of execution order; see that class's own Javadoc for why this is correct without comparing a timestamp or sequence number. Takes no arguments; reports "No query in memory" if neither source has ever produced a result yet in this session.

Both sources reuse renderTabSeparated for the actual formatting, so the clipboard's content is byte-for-byte the same table PULL ... AS TXT would write to a file: same NULL-as-blank-field, same per-type value formatting, same RFC 4180-style quoting for a value containing a tab/quote/newline (without which a value containing a tab would shift every column after it when pasted).

Clipboard access goes through ClipboardAccess, shared with <@clipboard>'s read side - same retry-on-transient-lock behavior, same clear error for a headless session.

Last modified in release 5.2.6.