Inspect the SQL behind your visuals

Inspect a visual's query to understand how its values were calculated. Unity retains authored SQL and, where model expansion or filters apply, can expose the executable statement prepared for the source.

Native visuals and HTML datasets both keep their analytical definition available for review.

Open the query

1. Select a data visual.
2. Open Adjust.
3. Inspect the source connection and authored SQL.
4. For an HTML visual with multiple datasets, choose the relevant Dataset.
5. Review returned columns, values, and available execution details.

Use the query copy controls to review the statement elsewhere. Editing access is required to save a changed definition.

Authored and executable SQL

These representations may be similar for a simple query. A logical entity backed by SQL, a reusable measure, or a relationship filter can introduce additional expressions or conditions into the executable statement.

Read an example calculation

Assume your model exposes orders, region, and amount:

SELECT region, SUM(amount) AS revenue
FROM orders
GROUP BY region
ORDER BY revenue DESC, region

The query returns one row per region. It sums amount, assigns the output name revenue, and orders the result. There is no date restriction in the authored statement.

If the visual is meant to show this quarter, inspect the effective saved and runtime filters. Do not infer the date scope from the chart title.

Replace the illustrative identifiers with those in your connection model and use its source SQL dialect.

Inspect model and filter expansion

The assistant can inspect the query plan and relevant model definitions. Ask for the calculation and its scope together:

Inspect the selected visual's authored SQL, executable SQL, parameters,
output mappings, and effective filters. Explain the grain of the result
and how the revenue measure is defined.

Model compilation can resolve entity SQL and reusable expressions. Applicable filters can add parameterized conditions and relationship-based restrictions.

When reproducing the result in a database client, use the executable statement with matching parameters, source identity, and time of execution. Authored SQL alone may omit context supplied by Unity.

Review the visual contract

A result table still needs correct visual mappings. Check category, value, series, and date fields against the actual SQL output names.

Review labels and number formats after changing a measure. A chart can display valid results under an obsolete title. A formatted date label is also different from the source value used for filtering.

For a detail table, inspect the complete key and its lineage before assuming a clicked row identifies one source record.

Edit the calculation

For native visuals, edit the query through the available inspector controls or ask the assistant to update the saved object.

For HTML, select the dataset, edit its SQL, and click Run & save query. Unity validates the query and registrations before saving. If a returned field is renamed, update every binding that still depends on the old name.

A dataset can serve multiple HTML visuals. Editing its query affects those consumers, not only the visual currently selected.

Change this dataset to use the existing net revenue definition.
Inspect all of its consumer visuals and update their bindings and labels
as needed. Verify the saved page after the change.

Distinguish query shapes

Database and imported-CSV queries use their supported SQL path. Public-data API connections use provider request descriptors and may apply a DuckDB transformation to returned rows. Do not paste an API request descriptor into a database SQL client.

See Public-data connections for that workflow.

Compare results reliably

Use SQL Playground for experiments before changing a saved visual.