Measure called inside an iterator over a large table
"Measure called inside an iterator over a large table" is one of the performance checks Auditabi runs on a Power BI semantic model. n expression(s) call another measure inside SUMX, AVERAGEX or MAXX over a fact table. It is a medium-severity finding: the model still works, but results are wrong in some filter contexts, slow, or fragile under change. Aggregate the columns directly inside the iterator, or move the measure call outside with a variable when the value does not depend on the row.
What is detected
n expression(s) call another measure inside SUMX, AVERAGEX or MAXX over a fact table. Each row triggers a context transition, which turns one storage-engine scan into one evaluation per row.
Why it matters
Wrong in some filter contexts, slow, or fragile under change. Fix in the next iteration.
How to fix it
Aggregate the columns directly inside the iterator, or move the measure call outside with a variable when the value does not depend on the row.
Reference
SQLBI: Context transition in DAX
Does your model fail this check?
Free static audit with the exact objects, no account, nothing stored.
More DAX checks
- Arithmetic or comparison on a measure that returns text
- Measure returning text in one branch and a number in another
- Share denominator clears a fact-table column instead of the dimension
- "Previous period" window overlaps the current one
- Percentage label built without ×100
- Percentages and amounts summed together