Forum Discussion
[Unable to combine data] error during update
Proceeding...
- I didn' try the 'ingore privacy' option in desktop, since desktop works fine. All this started when moving to Service, where that option, is not an option 🙂
- privacy levels reverting: INDEED. In desktop I double check everything yesterday: None. Now I check again: a OneDrive source reverted to "Organisational" ! Since data IS Organisational .. I'll now consistenly set that as privacy level. Maybe Service doesn't like 'None' for some reason resulting in unexpected behaviour... So I uploaded this 'sample BI' file to Service, again set everything to Organisational. Result: YES!!!! Now it works!
So, for reference to other users who have the same problem:
What solved the issue for me in the end, is (edit 15/3 to add one more step):
- To flatten the queries so that only one source is used per query/fuction/...
- to not use 'None' as privacy level. Set it to the correct level, whatever it is. I have the impression that Service doesn't handle 'None' well.
- the above query scheme and edits needed to make 'curRooms' work didn't mean that all other queries using the same scheme (for the other object types in the datamodel also relying on getTEobjects) also worked ... it required opening those queries in the advanced editor, making and undoing an edit and save. Just to trigger a real 'change/save' to those queries. Without doing so, the privacy error remained on those queries. It seems such such 'edit' is needed in order to force power BI to reevaluate the entire query scheme's privacy for each query.
Edit 18/3/25:
For completeness: the query dependencies now look like this, see below. Even if the 2 SOAP websources are still called exactly the same way, the flattening of the other source (onedrive excel file loaded into the 2 now orphaned config tables/queries) makes these web sources appear directly as input to getTEobjects. And hence, privacy can be managed in that function.
FYI: I've already witnessed several points where Service is much more strict than Desktop. (like circular references). And when I finaly found the 'true' cause, I must say I understand why Service is more strict in each case. It's just a pitty that it is not documented any better, and ther error reporting isn't helping much to direct you to the (not documented) solution.
Massive thanks for pointing me in the right direction v-ssriganesh
I tried following both your advise GilbertQ and v-ssriganesh
I created a new desktop BI file, limited to this single table 'curRooms' and the needed functions/parameters as above.
But now I get this 'new' error in desktop which I don't get on the full model, not in desktop or service :
Formula.Firewall: Query getTEobjects is accessing the data sources that have privacy levels which cannot be used together. Please rebuild this data combination.
The solution to this error in desktop I found was the 'flattening' tip from https://exceloffthegrid.com/formula-firewall-in-power-query/
In practise: rather than calling to construct the two queries 'TEobjectRelations' and 'TEobjectFields' as seperate queries, I 'copy paste' them into the getTEobjects query/function
Then uploaded into Service, I get following error on refresh:
- Fout in de gegevensbronInformation is needed in order to combine data. Please specify a privacy level for each data source.;Information about a data source is required.. The exception was raised by the IDbCommand interface. Table: curRooms
So I went to check the privacy levels and made sure, for the time being, that they are all consistently set to 'None' in both desktop and Service.
Desktop still OK, upload again in Service and privacy to None on both sources: still same error
Hi cdebackere,
Thank you for your detailed follow-up and for trying the suggested steps.
Here are a few additional steps you can try:
- Cross check the privacy levels for all data sources are set to "None" in both Power BI Desktop and Power BI Service, as they can sometimes revert to default settings.
For reference: Privacy levels: automatically change from "none" t... - Microsoft Fabric Community - In Power BI Desktop, navigate to File >> Options and settings >> Options >> Privacy and select "Ignore the Privacy Levels and potentially improve performance". This setting helps bypass privacy level checks. Understanding the Data Privacy Firewall can help structure queries to avoid conflicts. Refer to the article on the Data Privacy Firewall for more details: Understand Power BI Desktop privacy levels - Power BI | Microsoft Learn
- Verify that the credentials for all data sources are correctly set up in both Power BI Desktop and Power BI Service, as mismatched credentials can cause refresh issues.
- If issues persist, consider rebuilding the data combination from scratch, ensuring each step references only one data source at a time.
If this helps, then please “Accept it as a solution” and dropping a "Kudos" so other members can find it more easily.
Hope this works for you!
Thank you.
Proceeding...
- I didn' try the 'ingore privacy' option in desktop, since desktop works fine. All this started when moving to Service, where that option, is not an option 🙂
- privacy levels reverting: INDEED. In desktop I double check everything yesterday: None. Now I check again: a OneDrive source reverted to "Organisational" ! Since data IS Organisational .. I'll now consistenly set that as privacy level. Maybe Service doesn't like 'None' for some reason resulting in unexpected behaviour... So I uploaded this 'sample BI' file to Service, again set everything to Organisational. Result: YES!!!! Now it works!
So, for reference to other users who have the same problem:
What solved the issue for me in the end, is (edit 15/3 to add one more step):
- To flatten the queries so that only one source is used per query/fuction/...
- to not use 'None' as privacy level. Set it to the correct level, whatever it is. I have the impression that Service doesn't handle 'None' well.
- the above query scheme and edits needed to make 'curRooms' work didn't mean that all other queries using the same scheme (for the other object types in the datamodel also relying on getTEobjects) also worked ... it required opening those queries in the advanced editor, making and undoing an edit and save. Just to trigger a real 'change/save' to those queries. Without doing so, the privacy error remained on those queries. It seems such such 'edit' is needed in order to force power BI to reevaluate the entire query scheme's privacy for each query.
Edit 18/3/25:
For completeness: the query dependencies now look like this, see below. Even if the 2 SOAP websources are still called exactly the same way, the flattening of the other source (onedrive excel file loaded into the 2 now orphaned config tables/queries) makes these web sources appear directly as input to getTEobjects. And hence, privacy can be managed in that function.
FYI: I've already witnessed several points where Service is much more strict than Desktop. (like circular references). And when I finaly found the 'true' cause, I must say I understand why Service is more strict in each case. It's just a pitty that it is not documented any better, and ther error reporting isn't helping much to direct you to the (not documented) solution.
Massive thanks for pointing me in the right direction v-ssriganesh
Hi cdebackere,
Huge appreciation for sharing your findings and for your patience in troubleshooting this! 🎉
Your insights especially about Power BI Service handling privacy levels differently and the need to trigger query changes manually will be incredibly helpful for others facing similar issues.
Thank you once again for your detailed explanation. Could you please mark the helpful response as “Accept it as a solution” and give a "Kudos" to help other community members resolve similar issues more efficiently.