Forum Discussion
Regarding Data Load issue
- 1 month ago
Hi Thirumala,
Thanks for reaching out.
"The resultset…has exceeded the maximum allowed size of '1,000,000' rows" is the 1-million-row intermediate limit.Key point: it's not the 15 measures. Aggregations like SUM/COUNT get pushed to the source and return small results. The error means something in the visual makes Power BI pull a pre-aggregation result set of over 1M rows — usually:
- A high-cardinality field on rows/columns (an ID, order number, timestamp) being grouped.
- A measure that needs all distinct values of a high-cardinality / degenerate-dimension column (stored at line grain).
- Measure or Top N filters, which fetch all categories from the source before filtering.
the fix is to reduce the rows returned:
- Find the culprit first. Performance Analyzer → copy the visual's DAX → paste into DAX Studio and check the generated SQL. It shows exactly which column forces the large result. Don't optimise blind.
- Remove or raise the grain of that high-cardinality field (group by month/category, not line-level).
- Filter early so the intermediate set stays under 1M.
- Aggregation table (Import mode) holding just that column's distinct values, if a measure genuinely needs it — facts stay DirectQuery.
References:
https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-use-directquery
https://learn.microsoft.com/en-us/power-bi/guidance/directquery-model-guidanceBest regards,
Parchitect · Solutions Architect · Microsoft Fabric Specialist
Hi Thirumala,
Thanks for reaching out.
"The resultset…has exceeded the maximum allowed size of '1,000,000' rows" is the 1-million-row intermediate limit.
Key point: it's not the 15 measures. Aggregations like SUM/COUNT get pushed to the source and return small results. The error means something in the visual makes Power BI pull a pre-aggregation result set of over 1M rows — usually:
- A high-cardinality field on rows/columns (an ID, order number, timestamp) being grouped.
- A measure that needs all distinct values of a high-cardinality / degenerate-dimension column (stored at line grain).
- Measure or Top N filters, which fetch all categories from the source before filtering.
the fix is to reduce the rows returned:
- Find the culprit first. Performance Analyzer → copy the visual's DAX → paste into DAX Studio and check the generated SQL. It shows exactly which column forces the large result. Don't optimise blind.
- Remove or raise the grain of that high-cardinality field (group by month/category, not line-level).
- Filter early so the intermediate set stays under 1M.
- Aggregation table (Import mode) holding just that column's distinct values, if a measure genuinely needs it — facts stay DirectQuery.
References:
https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-use-directquery
https://learn.microsoft.com/en-us/power-bi/guidance/directquery-model-guidance
Best regards,
Parchitect · Solutions Architect · Microsoft Fabric Specialist