Saved Queries

Saved Queries allow a Point of View (POV) to be named and stored with a cube for reuse.

Instead of reconstructing the same multidimensional selection each time, define the POV once and save it under a meaningful query name.

For example, a Saved Query named:

Q1 Units by Month

could store:

{
  "MEASURES": ["Units", "Transactions"],
  "TIME": [{"children": "Qtr1"}],
  "YEARS": ["Curr Year"]
}

The Saved Query stores the multidimensional query definition. Casabase Cube can then reuse that POV interactively or execute it automatically on a schedule.

Saved Queries can also reference Cube Variables, allowing the same saved definition to follow changing periods, years, scenarios, or other selections.

Saved Queries and Query Execution

A Saved Query is fundamentally a named POV.

Conceptually:

Query Name
    +
Saved POV
    │
    ▼
Saved Query

The query engine still executes the POV using the normal Casabase Cube query process.

A Saved Query does not introduce a separate calculation mechanism.

For unattended execution:

Saved Query
    │
    ▼
Stored POV
    │
    ▼
QUERY_CUBE
    │
    ▼
Query Result

This distinction is important when working with Saved Queries programmatically.

QUERY_CUBE accepts a POV string. It does not accept a Saved Query name in place of the POV.

Creating a Saved Query in the UI

Saved Queries are managed from Vars & Saved Queries.

To create one:

1. Navigate to Vars & Saved Queries in the Casabase Cube sidebar.
2. Select the Saved Queries tab.
3. Select the cube.
4. Click the + icon on the Saved Queries grid.
5. Enter the QUERY_NAME.
6. Enter the POV.
7. Click Save Changes.

For example:

QUERY_NAME

Q1 Units by Month

POV

{
  "MEASURES": ["Units", "Transactions"],
  "TIME": [{"children": "Qtr1"}],
  "YEARS": ["Curr Year"]
}

The remaining system-managed fields are populated automatically as appropriate.

Saved Query Fields

The Saved Queries grid contains the stored query definition together with fields used to manage materialization and scheduling.

The primary user-defined fields are:

Field	Description
QUERY_NAME	Name used to identify the Saved Query.
POV	JSON Point of View executed by the query engine.

Additional fields can be populated automatically when materialization and scheduling are configured.

These include information such as:

Field	Description
TARGET TABLE	Table in SHARED_DATA containing the materialized query result.
SCHEDULE	Recurring schedule used to execute the Saved Query.
TASK STATE	Current state of the underlying scheduled task.

These scheduling-related fields do not need to be populated when creating a normal reusable Saved Query.

POV Syntax

The POV stored with a Saved Query uses the same syntax as any other Casabase Cube query.

For example:

{
  "MEASURES": ["Units"],
  "TIME": [{"children": "Qtr1"}],
  "YEARS": ["Curr Year"]
}

Saved Queries can use:

• Individual members
• Hierarchy selection operators
• Multiple selections within a dimension
• Cube Variables
• Any other supported POV construct

The Saved Query does not have a separate POV language.

See Point of View (POV) for the complete syntax reference.

Cube Variables in Saved Queries

Cube Variables are especially useful in Saved Queries because they allow a stored POV to remain dynamic.

For example:

{
  "MEASURES": ["Units"],
  "TIME": ["&CurrentPeriod"],
  "YEARS": ["&CurrentYear"]
}

The Saved Query definition does not need to be edited when the reporting period changes.

Instead, update the Cube Variable values and the next execution resolves the current values automatically.

Conceptually:

Saved Query
     │
     ├── &CurrentPeriod
     └── &CurrentYear
             │
             ▼
      Resolve Variables
             │
             ▼
        Execute POV

This is particularly useful for scheduled reporting.

See Cube Variables for variable syntax and behavior.

Managing Saved Queries with SQL

Saved Queries can also be created and maintained programmatically.

MANAGE_SAVED_QUERY

MANAGE_SAVED_QUERY supports:

ADD
UPDATE
DELETE

For example:

CALL CUBE.MANAGE_SAVED_QUERY(
    'ADD',
    '{
        "cube_name": "ASOSAMP",
        "query_name": "Q1 Units by Month",
        "pov": {
            "MEASURES": ["Units", "Transactions"],
            "TIME": [{"children": "Qtr1"}],
            "YEARS": ["Curr Year"]
        }
    }'
);

ADD, UPDATE, and DELETE identify the Saved Query by cube and query name.

The POV supplied through SQL follows the same rules documented in Point of View (POV).

Listing Saved Queries

Use:

CALL CUBE.GET_SAVED_QUERIES('ASOSAMP');

to retrieve the Saved Queries associated with a cube.

The result includes:

QUERY_NAME
POV
FORMULAS

The POV value is the query definition that can be supplied to QUERY_CUBE.

Running a Saved Query Programmatically

QUERY_CUBE does not accept a Saved Query name.

To execute a Saved Query programmatically:

1. Retrieve the Saved Query with GET_SAVED_QUERIES.
2. Obtain its stored POV.
3. Pass that POV to QUERY_CUBE.

Conceptually:

GET_SAVED_QUERIES
        │
        ▼
     Saved POV
        │
        ▼
   QUERY_CUBE
        │
        ▼
      Result

For example, after retrieving:

{
  "MEASURES": ["Units", "Transactions"],
  "TIME": [{"children": "Qtr1"}],
  "YEARS": ["Curr Year"]
}

execute that POV using:

CALL CUBE.QUERY_CUBE(
    'ASOSAMP',
    '{
        "MEASURES": ["Units", "Transactions"],
        "TIME": [{"children": "Qtr1"}],
        "YEARS": ["Curr Year"]
    }',
    NULL,
    NULL
);

This preserves a simple separation:

Saved Query
    =
Stored Query Definition


QUERY_CUBE
    =
Query Execution

Materializing a Saved Query

A Saved Query can also be used as the basis for a materialized reporting dataset.

Materialization executes the Saved Query’s POV through the Casabase Cube query engine and writes the calculated result to a table in SHARED_DATA.

Conceptually:

Saved Query
     │
     ▼
Stored POV
     │
     ▼
QUERY_CUBE
     │
     ▼
SHARED_DATA Target Table

The resulting table can then be consumed with normal Snowflake SQL:

SELECT *
FROM CASABASE_CUBE.SHARED_DATA.Q1_UNITS_DAILY;

Materialization is useful when a calculated result needs to be repeatedly consumed by dashboards, reports, applications, or other teams.

For the broader materialization use case and query behavior, see Querying with SQL.

Scheduled Saved Queries

A Saved Query can be scheduled to materialize automatically on a recurring basis.

A schedule defines:

• The Saved Query to execute
• The target table
• The execution schedule
• The Snowflake warehouse size
• Whether the schedule is active

Scheduling requires the CUBE_ADMIN role.

The scheduled process is:

Saved Query
    │
    ▼
Schedule Trigger
    │
    ▼
Execute Saved POV
    │
    ▼
Replace Target Table
    │
    ▼
Current Reporting Snapshot

The schedule does not create a different query type. It automates execution of the Saved Query’s POV through the existing query engine.

Materialize & Schedule in the UI

The Materialize & Schedule functionality associates a Saved Query with a recurring materialization process.

Once configured, scheduling information is reflected on the Saved Queries page, including fields such as:

Target Table
Schedule
Task State

This allows the Saved Queries grid to show not only the reusable query definition but also the operational state of its scheduled materialization.

A Saved Query does not need to be scheduled.

The same query can exist purely as a reusable POV without a target table or scheduled task.

Creating a Schedule with SQL

Use:

CALL CUBE.SCHEDULE_SAVED_QUERY(
    cube_name,
    query_name,
    target_table,
    schedule,
    warehouse_size,
    enabled
);

For example:

CALL CUBE.SCHEDULE_SAVED_QUERY(
    'ASOSAMP',
    'Q1 Units by Month',
    'Q1_UNITS_DAILY',
    'USING CRON 0 6 * * * America/New_York',
    'SMALL',
    TRUE
);

This schedules Q1 Units by Month to materialize into:

SHARED_DATA.Q1_UNITS_DAILY

The target table name must be unqualified. Casabase Cube creates the target in SHARED_DATA.

Schedule Formats

A Saved Query schedule can use a Snowflake cron expression.

For example:

USING CRON 0 6 * * * America/New_York

runs daily at 6:00 AM Eastern.

USING CRON 0 8 * * MON-FRI America/New_York

runs at 8:00 AM Eastern on weekdays.

USING CRON 0 */6 * * * UTC

runs every six hours.

Simple interval schedules are also supported.

For example:

60 MINUTE

runs hourly.

1440 MINUTE

runs daily.

Warehouse Size

A scheduled query can specify the warehouse size used for execution.

Supported values include:

XSMALL
SMALL
MEDIUM
LARGE
XLARGE

Choose a warehouse size appropriate for the expected query workload.

For most scheduled reporting queries, start with an appropriately small warehouse and increase the size only when query characteristics justify it.

Scheduled Results Are Replaced

Each scheduled execution fully replaces the materialized target table.

Conceptually:

Previous Snapshot
       │
       ▼
Scheduled Query Runs
       │
       ▼
Calculate New Result
       │
       ▼
Replace Target Table
       │
       ▼
Current Snapshot

Scheduled materialization does not append data to the existing table.

If historical snapshots are required, preserve the results separately through an appropriate downstream process.

Monitoring Schedules

Use:

CALL CUBE.LIST_SAVED_QUERY_SCHEDULES('ASOSAMP');

to review the schedules associated with a cube.

The result includes operational information such as:

Field	Description
QUERY_NAME	Saved Query being executed.
TARGET_TABLE	Materialized result table.
SCHEDULE	Configured cron or interval schedule.
WAREHOUSE_SIZE	Warehouse size used by the task.
STATE	Current task state.
LAST_RUN_AT	Last execution timestamp.
LAST_RUN_STATUS	Status of the most recent execution.
LAST_RUN_ROWS	Number of rows written by the last run.
LAST_RUN_MS	Execution duration.
LAST_RUN_ERROR	Error from the most recent failed execution, if applicable.
TASK_NAME	Underlying Snowflake task.

The reported task state reflects the current schedule state.

Running a Scheduled Query Immediately

A scheduled Saved Query can be executed without waiting for the next scheduled time.

Use:

CALL CUBE.RUN_SCHEDULED_QUERY(
    'ASOSAMP',
    'Q1 Units by Month'
);

This executes the configured Saved Query and refreshes its target table immediately.

The procedure is also the execution mechanism used by the scheduled task.

Pausing a Schedule

Use:

CALL CUBE.SET_SAVED_QUERY_SCHEDULE_STATE(
    'ASOSAMP',
    'Q1 Units by Month',
    FALSE
);

to suspend the schedule without deleting its configuration.

To resume it:

CALL CUBE.SET_SAVED_QUERY_SCHEDULE_STATE(
    'ASOSAMP',
    'Q1 Units by Month',
    TRUE
);

The query definition, target table configuration, and scheduling metadata remain in place while the schedule is suspended.

Removing a Schedule

Use:

CALL CUBE.UNSCHEDULE_SAVED_QUERY(
    'ASOSAMP',
    'Q1 Units by Month'
);

to remove the schedule.

Removing a schedule does not delete the materialized target table.

The table is intentionally left in place because downstream dashboards or other consumers may still depend on it.

Drop the table separately only when the data should also be removed.

Updating a Schedule

Calling SCHEDULE_SAVED_QUERY again for the same Saved Query replaces its existing schedule configuration.

This allows the schedule, target, warehouse size, or enabled state to be changed without creating a second scheduled definition for the same Saved Query.

Saved Query vs. Materialized Result

A Saved Query and its materialized table are related but distinct objects.

Saved Query
    │
    │ Query definition
    ▼
   POV


Scheduled Execution
    │
    ▼
QUERY_CUBE
    │
    ▼
Materialized Result

The Saved Query defines what should be queried.

The schedule defines when it should be executed.

The target table contains the calculated result from the latest execution.

This distinction matters because:

• A Saved Query can exist without materialization.
• A materialized table can remain after a schedule is removed.
• Changing the Saved Query changes what subsequent scheduled executions calculate.
• The target table represents a snapshot, not the query definition itself.

Saved Queries and Security

Scheduled query execution uses the Casabase Cube query engine and remains subject to the security context of the identity that executes the materialization.

A scheduled result is then stored as a plain materialized table. It is not dynamically re-filtered for each person who later reads that table. Do not use one scheduled materialized table to serve audiences that require different Casabase Cube row-level security scopes; query the cube under each user’s identity or materialize separate outputs for the intended audiences.

For interactive use, a Saved Query can produce different permitted results depending on the user executing its POV when that user has active Casabase Cube security rules.

Saved Queries and Default Members

Because a Saved Query stores a normal POV, default-member behavior applies to it exactly as it does to any other query.

If a dimension is omitted from a Saved Query:

• A dimension with no default member does not appear as an output column.
• A dimension with a configured default resolves to that default and appears in the result.
• The default can change the numerical result by slicing the query to the configured selection.

When building long-lived Saved Queries, explicitly include dimensions that materially affect the meaning of the report rather than assuming that omission always means a dimension-wide total.

See Point of View (POV) for the complete behavior.

Recommended Workflow

For a reusable query:

Build and Test POV
       │
       ▼
Create Saved Query
       │
       ▼
Reuse as Needed

For recurring materialization:

Build and Test POV
       │
       ▼
Create Saved Query
       │
       ▼
Configure Materialize & Schedule
       │
       ▼
Verify Target Table
       │
       ▼
Monitor Scheduled Runs

Test the POV interactively before scheduling it so that the Saved Query’s member selections, default-member behavior, formulas, and expected result shape are understood before downstream consumers begin using the materialized table.

Related Topics

• Querying Overview
• Query Builder
• Point of View (POV)
• Querying with SQL
• Cube Variables