Capabilities / SQL and exploration

Explore and save queries in SQL Playground

Execute read-only SQL, inspect result limits, save queries, and compare calculations with report visuals.

X4 Tech SolutionsUpdated September 10, 20263 min read

Use SQL Playground to run read-only queries, inspect a result table, and save queries for later. It is available through SQL in the report workspace.

Executing a query here does not automatically replace a report visual. Use the visual's inspector or a chat request when you want to update a saved object.

Run your first query

  1. Open SQL.
  2. Choose the Report and Connection.
  3. Enter a single read-only query using that source's model identifiers and SQL dialect.
  4. Click Execute.
  5. Review the returned columns, row count, execution time, and limit indicator.
SQL
SELECT region, COUNT(*) AS order_count, SUM(amount) AS revenue
FROM orders
GROUP BY region
ORDER BY revenue DESC, region

This example assumes those fields exist in your model. The report selector provides the relevant access and connection context.

Understand result limits

The default execution limit is 1,000 rows. When the result is limited, the interface shows Limited to 1000 and offers Get All Results.

That action removes the Playground's default preview limit. It does not remove an authored TOP or LIMIT, and source-specific safety limits, timeouts, or response-size limits can still apply.

For large datasets, prefer an aggregate or a deliberately bounded query. A limit indicator is part of the result's meaning.

Save and reuse queries

  1. Write or execute a query.
  2. Click Save Query.
  3. Enter a Query Name and click Save.
  4. Open Saved Queries to load it later.
  5. Use Delete Query to remove a saved query you no longer need.

The saved record includes the SQL and its report/connection context. Loading a query is different from executing it; inspect the selected context before running it again.

A saved query is also different from a reusable semantic-model measure. Use Data Definitions when a calculation should be shared consistently across visual authoring.

Use a read-only query

The query runtime is for supported read-only analysis. Do not use it to create tables, insert records, change source permissions, or run a batch of write statements.

Model entities can expand into source SQL during compilation. Use exact logical identifiers when querying the model rather than assuming they equal physical table names.

Imported CSV connections use the file-query path. API-provider request descriptors are not ordinary database SQL; use the public-data workflow for those sources.

Compare a visual with SQL

  1. Copy the visual's authored query and inspect its effective filter context.
  2. Choose the matching report and connection in Playground.
  3. Reproduce the relevant restrictions explicitly or inspect the prepared query and parameters.
  4. Execute and compare at the same grain and row-limit scope.

A query pasted into Playground does not necessarily reproduce every temporary click or saved visual-specific filter from the report.

Example prompt
Inspect the selected visual and explain how to reproduce its result
in SQL Playground, including model identifiers, date restrictions,
parameters, and any runtime selection that affects it.

Interpret errors

Error or discrepancyCheck
Unknown table or columnSaved model entities and exact field names.
Query rejectedRead-only, single-query rules and supported source dialect.
Permission deniedReport access and whether the connection is attached and usable.
Timeout or large responseQuery scope, aggregation, source performance, and result limits.
Different total from the visualConnection, filters, model expansion, row grain, and source timing.

Error details appear beside the results workflow. Read them before changing the SQL so a connection problem is not mistaken for a calculation problem.

Continue with Query inspection and Filters and interactions.

Questions about your environment? Contact us.