[Unable to combine data] error during update

[cdebackere]

Desktop BI running fine. Uploaded into Service: fine.

But then calling a refresh/update throws an exception:

[Unable to combine data] Section1/getTEobjects references other queries or steps, so it may not directly access a data source. Please rebuild this data combination.. The exception was raised by the IDbCommand interface. Table: curRooms.

I've read through some previous posts and tried to apply the solutions that were mentionned there. This includes: seperating seperate data sources in seperate queries / functions. And using staging to combine all info of all sources into the eventual querry/table to load into the datamodel.

But to no avail.

I've extracted from the power Query dependencies view the subset of this specific error. And added some information for you to clarify.

The above scheme might seem overly complicated, but the functions getTEobjects, getTEcertificateKey, getSoapResult also get used by other functions and other queries. In the figure above, I added to the links the information that is passed to the functions in order better understand.

In Service I configured the two sources' privacy level to None. And the data connections themselves are reported as working correctly. 

Why am I still getting this error?

BR,

Christof

[v-ssriganesh]

Hi @cdebackere,
Thanks for reaching out to the Microsoft Fabric Community.

Based on your description and the provided dependency diagram, here are the few steps you can consider:

• Please ensure each data source has its own query or function to isolate issues and identify problems more easily.
• Use staging queries to combine data from different sources into one query or table before loading it into the data model. This helps manage complexity.
• Double-check the privacy levels of your data sources. Even if set to None, it's worth revisiting to avoid conflicts.
• If the error message suggests, rebuild the data combination by revisiting the steps and queries to ensure correct configuration.
• Review dependencies and data flow using the Power Query dependencies view to identify issues or conflicts in the data combination process.

Simplify the functions involved in the data combination process if possible, to reduce complexity and make issue resolution easier.

Thank you @GilbertQ for sharing your valuable insights.

If this information is helpful, please “Accept it as a solution” and give a "kudos" to assist other community members in resolving similar issues more efficiently.
Thank you.

[cdebackere]

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

[v-ssriganesh]

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.

[cdebackere · Accepted solution]

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 

[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.

[GilbertQ]

Hi @cdebackere 

My only recommendation would be to take some of those functions and put them in a single table without referencing other tables to see if that works.