Multi-record CSV logo

Tagged records New

Query a Multi-record CSV with SQL — in Excel, Google Sheets, AI and REST

For CSV files that hold several kinds of record at once — a tag on each line says what that line is. Machine and interchange exports look like nonsense to normal CSV tools; this turns them into one clean table per record type.

One connection, every surface

Where your Multi-record CSV data can go

Query Streams turns a folder of tagged, multi-record CSV files into clean SQL tables readable from Microsoft Excel, Google Sheets, AI assistants over MCP, the REST API and Power BI. A tag on each line says what that line is, so the self-hosted agent routes it to the table for that record type — a file holding PNLHDR header lines and PNL1 detail lines becomes two proper tables instead of one unusable blob. Files stay on your machine; only query results leave the network.

One of 9 File Set drivers on one folder engine — the inventory tables, change trail and refusal rules under features are shared by the family Multi-record CSV File System CSV Folder Parquet Folder Excel Folder SQLite Folder JSONL Folder Machine Logs Web Server Logs

  1. For your team, vendors and partners
  2. Multi-record CSV to Excel Microsoft Excel · Excel add-in

    Pull live Multi-record CSV results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.

    How Excel works
  3. Multi-record CSV to Google Sheets Sheets add-on

    Run a saved Multi-record CSV query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.

    How Google Sheets works
  4. Ask Nova about Multi-record CSV Nova AI · text to SQL

    Ask a question in plain English. Nova already knows your Multi-record CSV tables, writes and runs the SQL, explains the answer and charts it — no query to write, no credentials to hand over.

    How Nova works
  5. Multi-record CSV to Data Viewer result sharing · team, vendors, partners · phone, tablet, desktop

    Share a live Multi-record CSV result with anyone — a colleague, a vendor, a partner — as a bookmarkable grid that re-runs fresh when opened, on a phone, a tablet or a desktop. They see the results, never the SQL or the files.

    How the Data Viewer works
  6. For apps and systems
  7. Multi-record CSV REST API HTTP endpoint

    Publish a Multi-record CSV query as an authenticated JSON endpoint any application can call, with an OpenAPI 3.1 spec and ready-made Postman, Insomnia and Hoppscotch collections. No database port is opened.

    How REST API works
  8. Multi-record CSV to Power BI Power Query M

    Paste the generated Power Query M into the Power BI Advanced Editor and the report reads live Multi-record CSV results over HTTPS — no ODBC driver, no database port opened.

    How Power BI works
  9. Multi-record CSV to Airtable Automation platform

    Sync Multi-record CSV rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.

    How Airtable works
  10. Multi-record CSV to Baserow Automation platform

    Feed a Baserow table from Multi-record CSV over the REST endpoint — self-hosted or Baserow cloud.

    How Baserow works
  11. Multi-record CSV to SeaTable Automation platform

    Keep a SeaTable base current with Multi-record CSV data without exporting a file or exposing the database.

    How SeaTable works
  12. Multi-record CSV to Smartsheet Automation platform

    Push Multi-record CSV results into a Smartsheet grid so plans and reports read from the source system, not last week's export.

    How Smartsheet works
  13. Multi-record CSV to Anvil Anvil Works · App platform

    Back an Anvil Python app with Multi-record CSV through the REST endpoint instead of embedding database credentials in the app.

    How Anvil works
  14. For AI tools
  15. Multi-record CSV MCP server Claude, Cursor and MCP clients

    Give an AI assistant read-only access to Multi-record CSV with the schema it needs to write correct SQL — no credentials in the chat.

    How MCP works
  16. Delivered to people
  17. Multi-record CSV alerts and reports Slack · Discord · Email · Webhook

    Put a Multi-record CSV query on a schedule and have the rows delivered to Slack, Discord, email or a signed webhook — or hold the message until a row count, threshold or percentage change crosses the line you set.

    How alerts and reports work

How it works

5 steps, no inbound firewall change

01

Install the Network Agent where it can see the folder of tagged CSVs — panel-saw and machine exports, EDI-style drops, fixed-format interchange files.

02

Point the connector at it and say which column holds the record tag. It is column 1 in most of these formats.

03

The agent reads each line, looks at its tag, and routes it to the table for that record type. A file holding PNLHDR header lines and PNL1 detail lines becomes two proper tables instead of one unusable blob.

04

Each row keeps its _source_file, plus a _seq number counting that record type through the file — which is what lets you tie a header back to the lines belonging to it.

05

Query each record type on its own, or join them back together.

Feature deep-dive

What Multi-record CSV gives you

Why this card exists

Ordinary CSV tools assume one rectangular layout per file: one header row, then rows that all match it. Machine and interchange formats break that rule on purpose. Every line begins with a tag saying what kind of record it is, and each type has a different number of fields. Point a normal CSV importer at one of these and you get an error or garbage columns.

How the tables come out

  • One table per tag — named from the tag itself, so PNLHDR and PNL1 become their own tables.
  • Fields land as field_1, field_2 and so on in the order they appear, with the tag column left out.
  • _seq numbers each record of a given type within its file, so a header and the detail lines under it can be matched up.
  • Types are worked out per field, per tag, and checked for agreement across the files before anything is pinned.
-- Panels cut, per export file
SELECT   _source_file, COUNT(*) AS panels
FROM     data_pnl1
GROUP BY _source_file

Errors are named, never swallowed

If a line carries the wrong number of fields for its tag, an unrecognised tag, or a value that does not fit, the whole file is held back and the report names the file, the line number and the tag — up to twenty of them, then a count of the rest. Nothing loads partially, so you are never chasing a total that is quietly short by three rows.

Not sure which card you need

If every line in the file has the same shape and there is a single header row, CSV Folder is the right card. Use this one only when a tag column decides what each line means.

Shared by the whole File Set family

Every folder connector also gives you

  • files_current — a live inventory: every file the connector can see right now, with its path, size and modified date.
  • files_events — the audit trail: what appeared, what changed, what vanished, and anything held back, with the filename and the reason.
  • directories and volumes — per-folder totals, daily growth history, and how much room is left on the drive.
  • Only files that actually changed are re-read on each sync, so a folder of 50,000 files is not re-parsed because one new export landed.

Good to know

  • Read-only, enforced — one statement at a time, SELECT and friends only. Your files are never written, moved or renamed.
  • Nothing is uploaded — the data is cached, encrypted, on your own machine beside the agent. Only the result of a query leaves your network.
  • Sensible defaults — up to 250,000 files, 16 folders deep, 512 MB per file, all adjustable. Recycle bins, .git and node_modules are always skipped.
  • The SQL dialect is DuckDB — the same SQL you would write against any other connector.

Cross-source SQL

Join Multi-record CSV to the rest of your data

A folder of files is a set of SQL tables like any other, so one statement can join it to a database and an API at once. Each source runs only the part it can, streams the result back, and the join happens centrally — the sources never talk to each other and nothing is copied anywhere.

3 connections · 3 agents

Multi-record CSV Tagged records
PostgreSQL Relational engine
Stripe Payments & billing

One statement

-- nothing copied, nothing merged, nothing scheduled
SELECT   c.region, COUNT(*) AS orders, SUM(i.amount_due) AS invoiced
FROM     machine_csv.fileset.data_pnlhdr1 f
JOIN     pg_crm.public.customers2         c ON c.id = f.customer_id
JOIN     billing.stripe.invoices3         i ON i.customer = c.stripe_id
GROUP BY c.region
ORDER BY invoiced DESC;

The three parts are connection, schema and table — and the connection name is whatever you called it. Illustrative columns; your tables will be your tables. Read-only applies to every piece: SELECT, WITH and EXPLAIN only, with a ceiling on how much any one source may hand over for a single query. How federated queries work

Connection details

What Multi-record CSV needs

Folder
One or more roots holding tagged CSV exports, subfolders included — panel-saw and machine output, EDI-style drops, fixed-format interchange files
Tag column
The column holding the record tag — column 1 by default, which is where these formats almost always put it
Tables
One per tag, named from the tag itself — a file of PNLHDR header lines and PNL1 detail lines becomes data_pnlhdr and data_pnl1
Columns
field_1, field_2 and so on in the order they appear, with the tag column left out; types are worked out per field, per tag, and checked for agreement across files before anything is pinned
Row keys
_source_file names the export and _seq counts each record of that type through the file, which is what lets a header be matched to the detail lines under it
Errors
A wrong field count, an unrecognised tag or a value that does not fit holds the whole file back; the report names the file, the line number and the tag, up to twenty of them, then a count of the rest
Limits
Up to 250,000 files, 16 folder levels deep, 512 MB per file — all adjustable
Credentials
None — there is no server; the agent reads the files in place
SQL dialect
DuckDB — standard SQL, nothing format-specific to learn

There is no database server in this picture. The agent reads the files where they already live, caches the rows in an encrypted DuckDB store on the same machine, and re-reads only files that actually changed — a year of machine exports is not re-parsed because this morning's landed. Nothing is uploaded to Query Streams; the only thing that ever leaves your network is the result of a query.

Ordinary CSV tools assume one rectangular layout per file: a header row, then rows that all match it. Machine and interchange formats break that rule on purpose — every line begins with a tag saying what kind of record it is, and each type carries a different number of fields. Point a normal importer at one of these and you get an error or garbage columns. If every line in your file does have the same shape and there is a single header row, CSV Folder is the card you want; use this one only when a tag column decides what each line means.

FAQ

Questions about Multi-record CSV

Which tools can read Multi-record CSV data through Query Streams?

All of them, from one connection: Excel, Google Sheets, MCP, REST API, Airtable, Baserow, SeaTable, Smartsheet, Anvil, Power BI, scheduled alerts and reports. Connect the folder once and every surface reads the same read-only connection — there is no per-tool setup and no second copy of the data.

Do my files get uploaded to Query Streams?

No. The Network Agent reads the files in place and caches rows in an encrypted store on the same machine. The files themselves never leave your network — only the result rows of a query do, over a single outbound encrypted connection with no inbound firewall port.

Can Query Streams change, move or rename my files?

No. Files are opened strictly read-only and are never written, moved or renamed. Queries are enforced read-only at the point of execution — one statement at a time, SELECT and friends only.

What does Query Streams need to connect to Multi-record CSV?

A folder path the agent machine can see — no server, no credentials, no drivers to install. Folder: One or more roots holding tagged CSV exports, subfolders included — panel-saw and machine output, EDI-style drops, fixed-format interchange files. Tag column: The column holding the record tag — column 1 by default, which is where these formats almost always put it. Tables: One per tag, named from the tag itself — a file of PNLHDR header lines and PNL1 detail lines becomes data_pnlhdr and data_pnl1. Columns: field_1, field_2 and so on in the order they appear, with the tag column left out; types are worked out per field, per tag, and checked for agreement across files before anything is pinned.

Can I join a folder of files to a database in the same query?

Yes — that is a federated query. One statement can reference Multi-record CSV and your other connections at once, written as connection.schema.table. Each source runs only the part it can and streams the result back; the join happens centrally, so the sources never connect to each other and nothing is copied or scheduled. Read-only applies to every piece — SELECT, WITH and EXPLAIN only — and there is a ceiling on how much any one source may hand over for a single query. Federated queries are a plan feature; the federated queries page carries the current source and size limits.

Put Multi-record CSV where the work happens

Install the agent, point it at your folder, and pick a destination.

Read-only Outbound only Credentials stay on the agent