Tagged records New
Connect Multi-record CSV to Excel, Sheets and AI
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
Connect Multi-record CSV once and the same read-only connection feeds all of these — no second setup, no second copy of the data.
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 no Multi-record CSV walkthrough written yet
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 no Multi-record CSV walkthrough written yet
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 no Multi-record CSV walkthrough written yet
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 no Multi-record CSV walkthrough written yet
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 no Multi-record CSV walkthrough written yet
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 no Multi-record CSV walkthrough written yet
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 no Multi-record CSV walkthrough written yet
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 no Multi-record CSV walkthrough written yet
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 no Multi-record CSV walkthrough written yet
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 no Multi-record CSV walkthrough written yet
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 no Multi-record CSV walkthrough written yetHow it works
5 steps, no inbound firewall change
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.
Point the connector at it and say which column holds the record tag. It is column 1 in most of these formats.
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.
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.
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_fileErrors 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.
- Requires Network Agent 2.6 or newer.
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
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
- Agent
- Network Agent 2.6 or newer
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.
Same folder engine
The rest of the File Set family
One engine, different file formats — the inventory tables, change trail and refusal behaviour are identical across the family.
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
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish