Forum Discussion
Error when refreshing on service using row limit parameter
- 1 year ago
Hi EpicTriffid
You're dealing with two separate but related issues:
-
"Column does not exist in dataset" – This typically happens when the
Keep Rowsstep is placed too early in the query, before Power Query finalizes the column structure (e.g., before Promoted Headers or Changed Type). Power BI Desktop might handle this leniently due to caching and more flexible evaluation, but the Power BI Service has stricter schema validation. When you change the parameter to "All" in the Service, it fails because the columns aren't guaranteed to exist at that point. To fix this, make sure your row filtering step comes after headers are promoted and types are applied. -
"DataFormat.Error: The number of items in the list is too large" – This is a hard limit you're hitting. You're trying to load a 16GB CSV file via SharePoint – that's not a sustainable or supported approach. Power BI doesn't load this type of file in a partitioned or indexed way. Instead, it reads it row-by-row through HTTP, which easily breaks when the data volume is that high. Even in Premium capacity, the problem isn't with model size or refresh capacity – it's with the source and how it's being accessed.
What to do instead:
-
Split the large CSV into multiple smaller files (e.g., by month or year), place them in a SharePoint folder, and use "Combine Files" in Power Query.
-
If possible, move the data into a proper structured data source – like SQL Server, Azure Data Lake, or even Dataflows.
-
Consider setting up Incremental Refresh so you're not reloading historical data on every refresh.
-
Avoid using dynamic row-limit logic (like "Keep Rows" with a parameter) before schema is fully defined.
Bottom line: Power BI Service is not built to handle 15M-row CSVs over SharePoint. It may work in Desktop, but that doesn’t mean it’s production-ready. The real fix is to shift to a better data architecture – not to tweak Power Query steps to squeeze one more refresh through.
If this post helps, then please consider Accepting it as the solution and giving Kudos to help the other members find it more quickly
-
Hi EpicTriffid
You're dealing with two separate but related issues:
-
"Column does not exist in dataset" – This typically happens when the
Keep Rowsstep is placed too early in the query, before Power Query finalizes the column structure (e.g., before Promoted Headers or Changed Type). Power BI Desktop might handle this leniently due to caching and more flexible evaluation, but the Power BI Service has stricter schema validation. When you change the parameter to "All" in the Service, it fails because the columns aren't guaranteed to exist at that point. To fix this, make sure your row filtering step comes after headers are promoted and types are applied. -
"DataFormat.Error: The number of items in the list is too large" – This is a hard limit you're hitting. You're trying to load a 16GB CSV file via SharePoint – that's not a sustainable or supported approach. Power BI doesn't load this type of file in a partitioned or indexed way. Instead, it reads it row-by-row through HTTP, which easily breaks when the data volume is that high. Even in Premium capacity, the problem isn't with model size or refresh capacity – it's with the source and how it's being accessed.
What to do instead:
-
Split the large CSV into multiple smaller files (e.g., by month or year), place them in a SharePoint folder, and use "Combine Files" in Power Query.
-
If possible, move the data into a proper structured data source – like SQL Server, Azure Data Lake, or even Dataflows.
-
Consider setting up Incremental Refresh so you're not reloading historical data on every refresh.
-
Avoid using dynamic row-limit logic (like "Keep Rows" with a parameter) before schema is fully defined.
Bottom line: Power BI Service is not built to handle 15M-row CSVs over SharePoint. It may work in Desktop, but that doesn’t mean it’s production-ready. The real fix is to shift to a better data architecture – not to tweak Power Query steps to squeeze one more refresh through.
If this post helps, then please consider Accepting it as the solution and giving Kudos to help the other members find it more quickly
Hi Ritaf1983,
Thank you so much for the incredibly comprehensive reply. Your explanations were fantastic and codified what I was already thinking!
- Ritaf19831 year agoSuper User
Happy to help and sorry that there is no simple solution 🙂
- EpicTriffid1 year agoHelper IV
Hi Ritaf1983,
Yup, it's an annoying quirk of being at an institution where they just won't allow use of SQL for datasets like this! Splitting up the source file and recombining in PQ should be a temporary fix until I can get them to sort out their data strorage!