Forum Discussion
Refreshes for Datasets containing Calculated Tables over Direct Query to AS started failing Mar 30th
Hi dbeavon3 ,
What I did:
- created a semantic model in fabric
- to add a calculated table, I opened this semantic model in power BI desktop (as the button is greyed out in fabric - acc. to Tom Martens post, that's correct for these thin reports
Solved: New Column in modeling tab greyed out - Microsoft Fabric Community
)
- in power BI desktop I was asked to create a local model in order to make changes on the model
- the local model is based on a direct query
- now, I added a calculated table (which was created in import mode)
- saved in power BI desktop locally in onelake for testing purposes and another time uploaded to fabric directly
- now the new model exists besides the original one
- the new model can't be refreshed because of mixed modes (this helps: Solved: Error message on publishing: "This dataset contain... - Microsoft Fabric Community In this post there is a link to Microsoft docu for composite models
Use composite models in Power BI Desktop - Power BI | Microsoft Learn )
)
- creating a new sso connection on report level caused a sucessful refresh
Yes, at first create the connection in the place of your screenshot. Then select the connection in your report.
I am not sure if this is the solution, but it worked for us.
Kind regards
Ilona
PunChili Thanks for the clear instructions.
This feature is working for me as well. The step related to creating a new connection supporting SSO is a bit odd. This shoudln't be necessary, considering that the scheduled refresh is the point when the calculation happens and, at that moment in time, the *only* applicable user credentials are the ones that are well known (I have "import" queries where we've already specified via OAUTH for the refreshing of the final model).
In any case, I'm glad we can get this working.
I was a bit disappointed to find that there is a 1 MM limit on the number of rows that can be pulled into a calculated table. It seems like this should be a lot higher, in cases where we are just moving data from one dataset to another, over direct query. I think there is a place in the service to override the 1 MM default. We may try increasing to 50 MM.