Skip to content
Casabase CubeCasabase Cube Documentation

Solve Order & Dependencies

Casabase Cube evaluates calculated members dynamically at query time.

Two related concepts determine calculation sequencing:

  • Dependencies determine which calculated members must be resolved before other formulas can be evaluated.
  • Solve order determines precedence when calculated members from different dimensions intersect.

These concepts are related, but they solve different problems.

Formula Dependencies

Section titled “Formula Dependencies”

A formula can reference another calculated member.

For example:

Revenue
Cost of Sales
     │
     ▼
Gross Profit
     │
     ▼
Gross Margin %

Gross Profit might be:

[ACCOUNT].[Revenue] - [ACCOUNT].[Cost of Sales]

and Gross Margin % might be:

[ACCOUNT].[Gross Profit]
/
NULLIF([ACCOUNT].[Revenue], 0)
* 100

Because Gross Margin % references Gross Profit, Casabase Cube must resolve Gross Profit first.

Dependencies Are Resolved Automatically

Section titled “Dependencies Are Resolved Automatically”

Casabase Cube detects calculated-member dependencies from formula references.

For example:

Formula A
    │
    ▼
Formula B
    │
    ▼
Formula C

does not require the administrator to manually assign a sequence simply to make B wait for A and C wait for B.

The engine resolves those dependencies automatically.

Circular Dependencies

Section titled “Circular Dependencies”

A dependency chain cannot ultimately reference itself.

For example:

Formula A
    │
    ▼
Formula B
    │
    ▼
Formula C
    │
    └────────► Formula A

has no valid evaluation order.

Circular references are detected and rejected during build processing. HEALTH_CHECK can report formula dependency problems.

Do not use solve order to try to correct a circular dependency. The formulas themselves must be restructured.

When Solve Order Matters

Section titled “When Solve Order Matters”

Solve order becomes important when calculated members from different dimensions intersect.

For example:

ACCOUNT  = Margin %
SCENARIO = Variance

If both selected members contain formulas, both calculations can apply to the same multidimensional cell.

Conceptually:

Calculated ACCOUNT
        ×
Calculated SCENARIO
        │
        ▼
Same Result Cell

Solve order determines which member formula is applied later and therefore takes precedence at that intersection.

Higher Solve Order Evaluates Later

Section titled “Higher Solve Order Evaluates Later”

Solve order is numeric.

The rule is:

Higher Solve Order
        │
        ▼
Evaluated Later
        │
        ▼
Takes Precedence

For example:

ACCOUNT.Margin %     SOLVE_ORDER = 10
SCENARIO.Variance    SOLVE_ORDER = 20

At their intersection, the SCENARIO.Variance formula is applied later because it has the higher solve-order value.

Solve Order Is Member Metadata

Section titled “Solve Order Is Member Metadata”

Solve order is configured per member through the SOLVE_ORDER metadata in the dimension definition.

For customer-created dimensions, include and map the applicable solve-order metadata when the model requires explicit precedence.

The effective values can be inspected through the cube’s dimension metadata view.

For example:

SELECT
    DIM_NAME,
    CHILD,
    SRC_SOLVE_ORDER
FROM CASABASE_CUBE.SHARED_DATA.<CUBE_NAME>_DIMENSIONS
WHERE SRC_SOLVE_ORDER IS NOT NULL
ORDER BY DIM_NAME, SRC_SOLVE_ORDER;

Replace <CUBE_NAME> with the actual cube name.

Example: Ratio and Scenario Variance

Section titled “Example: Ratio and Scenario Variance”

Assume:

ACCOUNT
└── Margin %          calculated


SCENARIO
└── Variance          calculated

The business requirement may be either:

Calculate Margin %
then calculate Variance

or:

Calculate Variance
then calculate Margin %

Those operations can produce different results.

Set the member solve-order values so the calculation that must take precedence has the higher value.

Do Not Use Solve Order for Normal Dependencies

Section titled “Do Not Use Solve Order for Normal Dependencies”

If:

Gross Margin %
    │
    └── references Gross Profit

the dependency itself tells Casabase Cube that Gross Profit must be resolved first.

You do not need to manufacture solve-order differences simply to express that ordinary dependency.

Use solve order when independent calculated members from different dimensions can meet at the same cell and precedence matters.

Do Not Use Solve Order as a Workaround

Section titled “Do Not Use Solve Order as a Workaround”

Solve order should not be used to compensate for:

  • An incorrect formula
  • A circular dependency
  • An incorrect member reference
  • An unexpected hierarchy structure
  • An incorrect POV
  • A missing dimension rebuild
  • An aggregation problem

Correct the underlying modeling issue first.

Equal or Unset Solve Order

Section titled “Equal or Unset Solve Order”

If intersecting calculated members do not require explicit precedence, additional solve-order configuration may not be necessary.

Only introduce deliberate solve-order differences where the business calculation requires one formula to be applied after another.

Query Limits

Section titled “Query Limits”

Solve order does not expand the calculation limits of the query engine.

A single query supports calculated members on at most two dimensions.

For example:

ACCOUNT   → calculated
SCENARIO  → calculated
VIEW      → calculated

uses calculated members on three dimensions and is refused.

Broad member selections combined with calculated members are also subject to calculation-scale safeguards.

Testing Solve Order

Section titled “Testing Solve Order”

When changing solve order:

  1. Identify the exact calculated-member intersection that requires precedence.
  2. Define the expected business result.
  3. Review the current member solve-order values.
  4. Apply the intended ordering.
  5. Run a representative query at the affected intersection.
  6. Compare the result with the expected value.
  7. Test nearby stored-member and calculated-member intersections to ensure the change has the intended scope.

Do not validate solve order using only a single isolated formula when the issue occurs specifically at a cross-dimensional intersection.

Troubleshooting

Section titled “Troubleshooting”

If a calculated result is unexpected, check in this order:

Formula Syntax
      │
      ▼
Member References
      │
      ▼
Formula Dependencies
      │
      ▼
Query POV / Grain
      │
      ▼
Hierarchy Aggregation
      │
      ▼
Security Scope
      │
      ▼
Cross-Dimensional
Solve Order

Solve order should generally be investigated after the simpler causes have been ruled out.

Key Takeaways

Section titled “Key Takeaways”
  • Formula dependencies are resolved automatically.
  • Circular dependencies are invalid and are rejected during build processing.
  • Solve order is primarily used when calculated members from different dimensions intersect.
  • Solve order is stored per member through SOLVE_ORDER metadata.
  • Higher solve order means the formula is applied later and takes precedence.
  • Normal calculated-member dependency chains do not require manual sequencing.
  • Solve order is not a workaround for incorrect formulas or modeling problems.
  • Solve order does not change the two-calculated-dimension query limit.
Section titled “Related Topics”