Edit and Export

A =DB.QUERY result is a spill: Excel won’t let you type into it. To edit data, you Materialize it into an ordinary Excel Table, change whatever you like, then Export the Table as a Parquet file. The file joins your local file sources straight away, so a query can read your edits without picking anything.

All three steps start from the Tables card in the task pane’s Home view.

Try it

Open the task pane’s Examples (the lightbulb) and run Materialize, edit and Export. It writes a source cell and a query over ten orders from the samples corpus on a fresh sheet, with the steps written beside the result:

A1: =DB.SOURCE("https://dev-fdb.sumpalabs.com/samples/sales.parquet", "sales")

A3: =DB.QUERY("SELECT order_id, order_date, region_id, product_id, quantity, revenue
               FROM sales
               ORDER BY order_id
               LIMIT 10", A1)

An Example can’t press task pane buttons for you, so the loop itself is yours: select A3, Materialize, edit, Export.

Materialize

Select something, then click Materialize. The new Table goes on a new sheet, so nothing you already have is overwritten.

• From a query result — select the cell holding =DB.QUERY, or any cell of its spill. formulaDB runs the query again and writes every row it returns, not just what the spill showed.
• From a local file — select the source cell of a local file source. The whole file is written into the Table, and the Table remembers which file it came from. Remote sources and range sources can’t be Materialized this way; query them and Materialize the query result instead.

Each Materialized Table gets a row on the Tables card. Materializing the same query cell or file again offers Go to Table, or Replace… to rewrite the existing Table’s rows in place, keeping its sheet and name so formulas that refer to it keep working. Replace asks first, because it discards your edits.

Values are written as real Excel values: dates and timestamps become Excel dates with a date format, numbers become numbers. A value Excel can’t hold without losing something is written as text instead — whole numbers beyond about 9 quadrillion (2^53), decimals with more than 15 digits, dates before 1900, and lists, structs and maps, which appear as DuckDB literals and are cast back on Export.

A result of more than 10,000 rows asks before it’s written. A sheet holds at most 1,048,575 rows, so anything larger is refused.

Edit

The Table is plain worksheet data. Change cells, sort, delete rows, add rows, add columns — formulaDB doesn’t track any of it. Nothing leaves the workbook until you Export.

Export

• A Materialized Table — click Export… on its row in the Tables card.
• A plain range, or a Table you made yourself — select it and click Export selection. The first row is the header. Selecting a single cell takes the whole block of filled cells around it.

Type a file name and click Export. formulaDB reads the cells, builds the Parquet file, then saves it — through a Save As dialog on Windows, as a download elsewhere (see what each host can do). An Export is always one Parquet file. The default name is the file the Table came from, or <Table name>.parquet for a query’s Table.

If the dialog doesn’t open within a few seconds of your click, the Tables card shows Ready — Save… (or Ready — Download); click it to finish. Discard drops the Export without saving.

How types are kept

Excel stores every number as a double and every date as a serial number, so a file that went through Excel would come back with DATE and BIGINT columns turned into DOUBLE. formulaDB avoids that by recording each Materialized Table’s column types, its Materialized schema, and Exporting to them. Each column’s type comes from, in order:

1. the Table’s Materialized schema, the types its query or file had when it was Materialized;
2. the existing file’s types, when the Export replaces a local file source;
3. the cells themselves, for plain ranges, Tables you made yourself, and columns you added.

From the cells, a column of Date-formatted whole numbers is a DATE, Date-formatted numbers with a time part a TIMESTAMP, whole numbers a BIGINT, other numbers a DOUBLE, TRUE/FALSE a BOOLEAN, and anything containing text a VARCHAR. Empty cells are always written as NULL.

The Materialized schema belongs to the Table and survives renaming it. A copied sheet or a pasted Table doesn’t carry one, so its Export infers types from the cells.

When an Export is refused

formulaDB never widens a type to make a cell fit. If a cell doesn’t fit its column’s type, the Export is refused and the message names the cell:

Could not Export Table Sales: Sales!B3 holds "next week", which is not a DATE (column order_date). No file was created.

An Export is also refused for an error cell such as #N/A, a blank header, or a header used twice. Fix the cells and Export again. To change a column’s type on purpose, cast it in the query (CAST(quantity AS DOUBLE) AS quantity) and Materialize again.

Exporting over a file

When an Export replaces a local file source the workbook already uses, its source cells are refreshed and every query reading the file recalculates against your edits. If the new file drops a column, changes a column’s type or has fewer rows than the old one, formulaDB asks first:

Exporting over sales.parquet drops column region_id. Rows: 12,480 → 8. Export anyway?

Saying no leaves the file as it was: “Export cancelled. sales.parquet was not changed.” Only Excel on Windows can replace a file on disk; on the web and on a Mac an Export always takes a new name.

What each host can do

Host	How Export saves	Replaces an existing file	formulaDB knows the saved name
Excel on Windows	A Save As dialog	Yes — the file on disk is replaced, and the queries reading it recalculate	Yes, from the dialog
Excel on Mac	A download	No — the save panel asks Replace? but leaves the old file in place	No — it uses the name you typed
Excel on the web	A download	No — the browser saves a clashing download as name (1).parquet	No — it uses the name you typed

On the web and on a Mac, an Export can’t take the name of a file you’re already using; formulaDB suggests the next free name instead (sales_1.parquet, then sales_2.parquet). After the download, check its name. If your browser saved it under another one, rename the download to the name formulaDB used, so that Reconnect finds it when you next open the workbook. The download goes wherever your browser saves downloads; move it next to your other sources.

On a Mac, the task pane also reminds you that replacing an existing file doesn’t work there, even when the save panel offers to.

Re-point

When you Export a file’s Table under a new name — always on the web and on a Mac, and on Windows when you pick another name in the dialog — the source cells that read the old file still read it. The success message then offers to move them:

2 Source cells still read sales.parquet — Point them at sales_1.parquet

Re-point changes only the file name in those =DB.SOURCE cells and keeps their aliases, so no query’s SQL changes. A single Ctrl+Z puts the cells back. It’s an offer, not automatic, because a new name may be a deliberate copy rather than the file’s next version. The old file stays available, so you can point the cells back. A source cell that builds its file name from other cells is listed and left alone.

After a Re-point, the Table’s next Export defaults to the new file.

Cancel and failures

While a Materialize runs, or an Export reads the cells and builds the file, the Tables card shows Cancel. One Materialize, Export or Re-point runs at a time.

• A cancelled or failed Materialize removes the sheet it was writing, so the workbook is left as it was: “Materialize cancelled. The workbook was not changed.” A cancelled Replace leaves the Table’s old rows.
• A cancelled or failed Export creates no file: “Export cancelled. No file was created, and the File registry was not changed.” Cancelling the Save As dialog does the same.
• A failed save on Windows. Windows empties a file as soon as you pick it in the Save As dialog. If writing fails after that, the message says so, and formulaDB still holds the Export: click Download instead to keep your edits.
• Too large. An Export that runs out of memory inside Excel says so and creates no file; Export fewer rows or columns.

Limits worth knowing

• 1900 date system only. Dates are read and written in Excel’s default 1900 date system. A workbook set to the 1904 date system will show Materialized dates four years off.
• About a millisecond of precision. Excel stores dates and times as doubles, so anything finer than about a millisecond in a TIMESTAMP or TIME is lost in a round trip.
• Local files only. An Export never writes to a remote URL. Remote sources are read-only.
• The Materialized schema belongs to this build of formulaDB. A workbook opened in a different build of formulaDB sees its Materialized Tables as plain Tables, and their Exports infer types from the cells.

Next

• How it works — local file sources, re-picks, and Reconnect.
• =DB.SOURCE — bind a local file, including the one you just Exported.
• =DB.QUERY — the query a Materialize runs again.