Live queries and data handling

Unity runs analytical queries against each report's model and the sources its named entities reference. Reports store the definitions needed to repeat those queries: source bindings, SQL, field mappings, filters, and presentation.

“Live” describes that connection to the source. It does not mean every result continuously streams updates, every screen shares one transaction, or nothing is stored.

Refresh a report

1. Open the report and select the page you want to inspect.
2. Check the active saved filters and temporary chart selections.
3. Use the visual refresh controls, or Refresh live data on an HTML page.
4. Wait for the query and rendering states to settle.
5. Inspect the returned data and effective SQL if a value differs from your expectation.

For an HTML page, one refresh can execute several registered datasets. A visual may keep its previous display while showing that new data is loading. Use the settled result when evaluating the page.

What stays live and what is saved

Ask a new question or rerun the relevant analysis to get a fresh answer in chat. Reopening an old conversation does not recalculate every previous statement.

Caching and freshness

Some visual execution paths reuse recent results, including a five-minute refresh-cache window in the native visual cache policy. Other paths query again. Do not treat that cache window as a refresh schedule or a universal guarantee for every screen.

Later table pages can reuse a temporary ordered result for the same query, model, actor, and parameters. This makes paging faster but can retain that result's source-time snapshot until it expires or a new query/filter context is read. Imported Parquet can also be cached locally; it is the same immutable imported dataset.

Results from different visuals can be requested at different times. If the source changes during a multi-query report refresh, the page is not necessarily a single database snapshot.

Refresh the analysis for the latest available data. Report the date range,
source, and effective filters used. If a result is cached or incomplete,
make that clear before comparing it with the previous answer.

For a reproducible comparison, align source, query, time range, filter values, and execution time.

Row limits and paged results

A returned table is not automatically the complete dataset. SQL Playground starts with a 1,000-row limit. HTML snapshot datasets are bounded, while paged HTML tables retrieve additional result windows.

These are output limits. The engine has no fixed 250,000-row source-input cap: a small aggregate can process millions of rows within its memory and disk budgets. A complete result beyond an endpoint's row/byte bound fails explicitly. See Query processing.

Use a separate aggregate query for a total across the full dataset. Summing only the rows currently loaded in the browser can produce a partial total.

SELECT COUNT(*) AS order_count, SUM(amount) AS revenue
FROM orders

This example assumes a model entity named orders and a numeric amount field. Replace them with your model's identifiers and apply the intended filters.

An authored TOP or LIMIT is part of the query's meaning. Loading another page does not remove that restriction.

HTML previews use fresh execution

The assistant's HTML preview renders saved source with live dataset execution and saved filters. It may show newer source data than your browser's last render.

Temporary clicks in your open report are not automatically reproduced in an isolated preview. A rendering comparison should use the same page revision, viewport, theme, and effective filter state. See HTML rendering and testing.

Troubleshoot unexpected values

Use Query inspection to trace the calculation and Filters and interactions to inspect its scope.