Forum Discussion
Power BI Custom Visual – update() function resets dataView to 30k rows after drill up/down
Hi Hieudao
Thanks for sharing such detailed explanation.
The configuration confirms that Power BI is applying a windowed data reduction of 30,000 rows. This behavior is by design in Power BI.
When you drill up/down or navigate back to the page, Power BI reinitializes the visual and sends a fresh dataView starting from the first 30k rows. Even if you previously fetched all rows (105k), the visual does not persist that state across page navigation.The inconsistent columns/rows you observed (6 columns → 5 columns, 30k rows → 52k rows → back to 30k rows) happen because drill changes alter the schema (columns).
To fix fetching data:
In update(options), check options.type:
If VisualUpdateType.All or VisualUpdateType.Data → clear previous cache and start fetching again.
Always assume update() after drill or navigation is a fresh start.Hope this helps !!
Thank You
Hi Hieudao
Thanks for the detailed explanation. Just to clarify the behavior
The behavior occurs only during the visual reinitialization phase after page navigation. During report development or normal refresh, the visual functions correctly. However, upon returning to the page, Power BI rehydrates the visual with a truncated dataView (limited to 30,000 rows), leading to incorrect drill up/down behavior.
Could you confirm:
- Is your custom visual configured with a "dataReductionAlgorithm": { "window": { "count": 30000 } } limit in your capabilities.json?
- Are you using import mode or DirectQuery mode for the dataset?
- When navigating back to the page, does Power BI trigger update() immediately with a partial dataset ?
- If you manually call this.host.fetchMoreData() on page return, does Power BI respond with additional rows, or does it stay at 30k?
Hi v-aatheeque
I will answer your questions:
1. In capabilities.json file I configured "dataReductionAlgorithm": { "window": { "count": 30000 } }2. I import data from excel workbook
3. yes, when i go back to the page with 105k data it will call 30k - 59k - 89k - 105k in turn.4. When I returned to the page containing the custom visual, Power BI started returning data in chunks through multiple calls to the update() function.
Specifically, the data was returned in the following order:
Cast 1: Columns: 6, Rows: 30,000
Cast 2: Columns: 6, Rows: 52,000
(loading…)
Cast 3: Columns: 5, Rows: 30,000
However, when I drilled up, the actual correct data for the dataset at that level was 52,000 rows.
So:
Cast 1 and 2, the number of columns was wrong but the number of rows was right.
Cast 3, the number of columns was right but the number of rows was wrong.
Sumary:When returning to the Power BI page, the custom visual receives multiple update() calls with inconsistent data. The data is returned in chunks (30k → 59k → 89k → …), and when drilling up, the number of columns and rows between update() calls do not match.
Specifically:
1st & 2nd times: columns are wrong, rows are right.
3rd time: columns are right, rows are wrong.
The actual correct data should be 52k rows with 5 columns.
ThanksHi Hieudao
Thanks for sharing such detailed explanation.
The configuration confirms that Power BI is applying a windowed data reduction of 30,000 rows. This behavior is by design in Power BI.
When you drill up/down or navigate back to the page, Power BI reinitializes the visual and sends a fresh dataView starting from the first 30k rows. Even if you previously fetched all rows (105k), the visual does not persist that state across page navigation.The inconsistent columns/rows you observed (6 columns → 5 columns, 30k rows → 52k rows → back to 30k rows) happen because drill changes alter the schema (columns).
To fix fetching data:
In update(options), check options.type:
If VisualUpdateType.All or VisualUpdateType.Data → clear previous cache and start fetching again.
Always assume update() after drill or navigation is a fresh start.Hope this helps !!
Thank You
