Skip to content

Computed Tables FAQ

Referencing and Joins

Can a Computed Table reference another Computed Table?

No. Computed Tables are stored as metadata inside Qualytics; they are not created as real views or tables in the warehouse. When the warehouse runs the query, it cannot resolve a Computed Table by name. If you need to chain logic, merge the intermediate step into a single query using a CTE (WITH ... AS (...)), or materialize the intermediate result as a real view or table in the warehouse and sync it into Qualytics.

Can a Computed Table join tables from different datastores?

No. A Computed Table only sees the base tables and views of its own parent datastore. For cross-datastore joins, use a Computed Join.

Can I use a Computed Table as an input to a Computed Join?

Yes. A Computed Join can be built on top of tables, views, Computed Tables, or Computed Files as long as each input has been profiled. The only input a Computed Join cannot accept is another Computed Join.

Parameters and Dynamic Values

Can I use parameters or variables in a Computed Table query?

No. The query is stored exactly as you write it and sent to the warehouse as is, so placeholders such as :start_date or variables in double curly braces are not replaced with values. Scan and Materialize operations cannot change the query either. To make a query adapt over time, use one of the approaches in the next question.

How do I change a date range or filter across several Computed Tables without editing each query?

Choose the approach that fits how the value changes:

  • A control table in your warehouse. Keep the current values (for example a reporting period start and end date, or a business unit) in a small table in the same datastore, and join each Computed Table's query to it. When the period changes, update that one table; every Computed Table that references it picks up the new values the next time it is read.
  • Warehouse date functions. For rolling windows such as "the last 30 days", use your warehouse's own functions (for example CURRENT_DATE - INTERVAL '30 days'), so the window moves forward on its own.
  • Runtime variables in check filters. Keep the Computed Table broad and apply the changing value in its checks instead. A check filter can reference a variable whose value comes from the container's Additional Metadata or is supplied for each scan. See Use Runtime Variables.
  • Update the query automatically. The query can be changed through the API or the Qualytics CLI. Each update validates the query and re-profiles the Computed Table, so this suits occasional changes rather than every run.

Materialization and Cost

Are Computed Tables materialized in the warehouse?

No. The SQL query is stored as metadata inside Qualytics and executed against the live warehouse every time the container is scanned, profiled, or previewed. Nothing is written back to the warehouse.

Does saving a Computed Table trigger a scan?

No. Saving persists the definition and runs a basic profile that samples up to 1000 records per partition so field statistics appear immediately. A full profile and any scans run only when you or a schedule kick them off.

How can I reduce the cost of a slow Computed Table?

The query runs every time the container is scanned or profiled, so slow queries scale their cost with scan frequency. To speed things up: narrow with a WHERE clause, use warehouse-native indexes and materialized views for heavy joins, and consider moving very heavy preparation into a real warehouse view that Qualytics syncs as a base container.

Connector Behavior

Why does my SQL Server / Oracle / Redshift query fail with "table not found"?

These connectors require fully-qualified names. Table names dropped from the modal's picker are already prefixed with the datastore's schema. If you hand-type a reference (or point to a table in a different schema), qualify it explicitly as SCHEMA.TABLE in the query body.

Where does the Computed Table SQL execute?

In the parent warehouse. Qualytics sends the SQL to the datastore's JDBC connection and treats the returned rows as the container's data. Write the query in whichever dialect the warehouse expects (Oracle SQL for Oracle, T-SQL for SQL Server, Redshift SQL for Redshift, Snowflake SQL for Snowflake, and so on). This is different from Computed Files, which run through Qualytics's own Dataplane.

Editing and Timeline

Does editing the query re-run the profile?

Yes. Saving an edit immediately triggers a synchronous slim profile so field statistics refresh right away, followed by a full asynchronous profile. Existing quality checks are preserved, and anomalies raised against the older version remain in the anomaly history.

Can I see previous versions of the query?

Yes. Open the container's Timeline to see the query changes in order. Query changes collapse behind a View changes control, whatever their size, that opens the previous and new versions side by side, with the changed lines highlighted and a copy button on each side, along with the user and timestamp for that change.

Permissions

Who can create a Computed Table?

Any user with the Editor or Author team permission on the parent datastore. Authors can only create Computed Tables they own themselves; Editors can create Computed Tables owned by any user.

Who can reassign ownership?

Only users with the Editor team permission. Authors cannot change the owner of a Computed Table, even one they own.