See the SQL behind your visuals

See a visual's fields and the SQL Unity generates from them, to understand how its values were calculated. A visual stores a visual query over your report model, never SQL; the generated SQL is read-only.

Read a visual's fields

1. Select a chart, card or matrix.
2. Open Adjust, then Fields.
3. Read what it is Grouped by, its Values (such as Sum of Orders › Amount), how it is Sorted by and its Top N, with the table and field names the Data panel shows. A model measure reads as its table and name.

A table's columns are its fields, so a table has no Fields section. For an HTML visual with multiple datasets, choose the relevant Dataset; its generated SQL shows there.

Nobody edits a visual's query by hand: ask the assistant, or your own AI over MCP, to change it. Filters are not part of the query; the filter pane shows them.

See the generated SQL

The Adjust panel doesn't show a native visual's SQL. Ask the assistant, or your own AI over MCP, which reads it with the visual:

Show the SQL the selected visual's query generates.

Read an example

A bar chart grouped by Orders › Region with the value Revenue: Sum of Orders › Amount generates SQL like:

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

The query returns one row per region. There is no date restriction in the query itself. If the visual is meant to show this quarter, check its filters; do not infer the date scope from the chart title.

Calculated fields and measures are defined once in the report model, in DuckDB SQL, and the generated SQL names them. Ask the assistant to explain one:

Explain the selected visual's query: its grain, its filters, and how
the revenue measure is defined in the model.

Where a query runs, and how Unity compares text

Unity's DuckDB engine computes every report query from the source outputs it needs; for SQL Server it can first reduce those outputs at the source, exactly. Text comparison, grouping, and sorting use Unity's engine; they do not inspect or cache the database's collation rules.

Unity compares text by one rule, with case-insensitive behavior familiar from Power BI:

The rule applies to filters, comparisons, joins, grouping, distinct counts, minimum and maximum, and ranking. Searches with LIKE, contains, starts with, and ends with ignore case only: accents, width, and kana count.

Text sorts in one fixed Unicode order, the same for every report and language: punctuation and symbols first, then digits, then letters, with an accented letter right after the plain one. A table with no sort of its own is sorted by its first column, then the next, left to right, ascending, with text in this order.

When several spellings fall into one group, the group shows its first spelling. An imported file is stored with each value's first spelling in the file, as Power BI's import does, so its rows show that spelling too; the import tells you how many values it stored this way. Over a database, whose rows have no order, the group shows the spelling that sorts first in code-point order, so the label is the same on every read, and rows that are not grouped keep their stored text.

To compare text exactly, including case and spaces, write COLLATE C in the query, for example WHERE Region COLLATE C = 'East'. Over an imported file it sees only the stored first spellings.

On a case-sensitive database, such as Snowflake, Databricks, or PostgreSQL, Unity's answer can differ from running the same SQL in that database directly: Unity counts East and east as one value, the database counts two.

Unsupported text constructs report an explicit query error rather than rejecting a language as a whole. The runtime sql guide lists the admitted functions and restrictions. Query processing explains large inputs, source reductions, and result windows.

Letters added in the newest Unicode versions are compared exactly, by case and code point, until Unity's engine supports that version.

The assistant's QueryDataModel result identifies the execution engine. Source SQL is only part of the calculation, so copying a fragment to SSMS does not reproduce the final report result.

Change the calculation

Ask the assistant to change the visual's query or the model field it reads. For HTML, a dataset is a visual query like a native visual's: select the dataset to read its generated SQL, and ask the assistant to change its query. If an output is renamed, every visual script that reads the old name needs the new one.

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 measure.
Inspect all of its consumer visuals and update their scripts and labels
as needed. Verify the saved page after the change.

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.

Compare results reliably

Ask the assistant to preview a changed visual query before it saves the visual.