Forum Discussion
Handling Schema Changes in Import Mode – Dynamic Columns in Power BI Service
Hi Anonymous ,
We found a feasible workaround to handle the schema update issue using XMLA endpoint with C#(.NET).
The implementation is in progress.
Thank you.
Hi ibarrau . Firstly thanks a lot for spending some time to reply for my post.
I agree with your answer, But wanted to add extra info for my post.
We are facing above issue in "self servicing" Power BI report where end users create their own visuals from deployed dataset.
They also have access to create extra fields under "User Defined Fields" category from ERP, which I referred as "extra columns / new columns" earlier.
So we use same semantic model across multiple databases and multiple users where UDFs won't be same across all the cases and for some cases there won't be UDFs at all.
In such cases when we switch from one env(having UDFs) to another env(with no UDF) by changing Server, DB parameters we encounter the error shown in the snap.
Any thoughts that will help us in this context would be appreciated.
Even after reading at your reply I tried by modifying query in power query editor just to "Select * from table" rather than mentioning necessary fileds as earlier and tried repoducing the scenario with env switch in PBI service.
But again encountered the same error.
Alright, let's talk new alternatives. If UDF scenario brings the whole universe of columns and data, then the best approach is getting that data to the semantic model. Then you can use OLS to prevent users of viewing some columns.
https://learn.microsoft.com/en-us/fabric/security/service-admin-object-level-security?tabs=table
As an alternative if you only have two sets of columns possibles, you could build two semantic models. This approach works but you have rework each time you want to do some operations to the table.
Coming back to the power query code. Try pick up a table from the UI when connecting to source instead of a query. Then make sure there is no further steps using columns names. The engine by default adds Change Types step each time you try a getting data step. Changing types always talks about specific columns in the code.
I hope that helps,
ibarrau I should think about OLS option but we already use RLS, which can be considerable point.
But main point is that we are unaware of the new columns count and their names and at which point they gonna added to database also now known earlier.
Reg. alternate option of each time changing in desktop and republishing won't work in our case. Since we wanted to automate the whole process through pipelines.