Forum Discussion
Direct Query warning message when trying to publish
Hi
I went to publish my dashboard that has one direct query. This direct query does not have any relationships created with any of my other tables, nor have I created any calculated tables or columns in or to that direct query dataset. Why would I be getting the error "this semantic model contains calculated tables or calculated columns that refer to remote tables" when I go to publish?
Hi siddrow ,
You can follow the below 3 options.
Option 1: Keep Logic Out of Composite Model (No Calculated Tables/Columns)
Avoid any calculated tables or columns that reference the DirectQuery dataset. Only create measures, and make sure those do not reference imported tables in their logic. Consider moving some transformations to Power Query (for import-mode tables).
Keep DirectQuery and Import parts completely decoupled (no relationship, no measure linking them).Option 2: Split into Two PBIX Files
This is the most stable and scalable option.PBIX 1 Live Dataset Model: Only connects to the shared DirectQuery dataset. Build all visuals and measures that rely on it. Publish it as a standalone Power BI report or dataset.
PBIX 2 Import Model: Connects to your other data sources. Create local measures and logic here.
In PBIX 2: Use Power BI datasets to connect to the published dataset from PBIX 1. This avoids calculated tables/columns issues because the entire remote dataset is treated as a semantic model, not raw tables.
Note: You can now reuse that dataset across multiple reports without hitting DirectQuery limitations.
Option 3: Use Dataflows as a Middle Layer
Useful if you want more control over the shared data or want to reuse across models. If the source data is available in a Power BI Dataflow , import that instead. You can schedule refreshes and shape the data in Power Query without relying on DirectQuery constraints. This gives you Import-mode flexibility, but still aligns with governance (if the dataflows are created in your organization’s workspace).If my response has resolved your query, please mark it as the Accepted Solution to assist others. Additionally, a 'Kudos' would be appreciated if you found my response helpful.
Thank you
8 Replies
Hi siddrow I got a similar error before. It took sometime to figure out that the warning error was due to a measure that combined a direct query and import source. Regardless, the measure would still refresh fine in the service and the associated report was still viewable by the other users without any issues.
Hi siddrow ,
Thank you for reaching out to the Microsoft Community Forum.
This is a common issue with DirectQuery models in Power BI, especially when mixing data sources.
Here’s why you might be seeing the error:"This semantic model contains calculated tables or calculated columns that refer to remote tables"
This error is usually triggered when DirectQuery and Import mode are being mixed in a way that violates certain restrictions in the Power BI composite model rules.
Can you please check below reasons for the Error:
1.Hidden Relationships or References: Even though you haven’t explicitly created relationships or calculated columns, Power BI might have automatically inferred or created metadata-level dependencies, especially if you've: Created a measure that references both import and DirectQuery tables. Used a DirectQuery table in a visual alongside imported tables. Used DAX functions that implicitly access columns from multiple tables.
2.Model Automatically Creating Relationships or Cache: When a report is being built, Power BI might attempt to auto-create relationships or optimize the model in ways that aren’t obvious in the UI.
3.Calculated Measure References: If a measure (even if not obviously tied to the DirectQuery table) references a column from the DirectQuery source, it can be treated like a calculated column/table in the context of semantic model validation.
4.Power BI Desktop Bugs or Version Conflicts:
There are occasional version-specific bugs where stale metadata or invisible relationships cause publishing issues. Always make sure Power BI Desktop is up-to-date.Please check below things:
1. Check Measures
Review all your measures to see if any of them reference the DirectQuery table, even indirectly.2. Check for Auto Relationships
In Model view, see if any relationships were automatically created between the DirectQuery table and others. Delete them if they exist and aren’t needed.3. Try Removing the Table Temporarily
Delete the DirectQuery table temporarily.Try publishing.
If it works, that confirms the DirectQuery table is being flagged. Then try re-adding the DirectQuery table in a separate pbix file and re-importing the visuals or logic as needed.
4. Use Performance Analyzer or DAX Dependency View
These tools help see which visuals or measures are referencing which tables behind the scenes.Do changes to fix the issue:
Convert the DirectQuery table to Import if it’s not required to be live. Keep the DirectQuery dataset in a separate pbix file and use Power BI dataflows or composite models with shared datasets.
Can you please refer community forum thread
Solved: Re: Unable to Publish Report with DirectQuery and ... - Microsoft Fabric Community
If my response has resolved your query, please mark it as the Accepted Solution to assist others. Additionally, a 'Kudos' would be appreciated if you found my response helpful.
Thank youHi
Thanks for your response. I have already checked the measures and auto relationships and didn't find anything. This dataset was a shared dataset, which could only be brought in via Directquery, not import. Import setting is disabled for this dataset, so I cannot convert it.
If I delete the dataset and confirm that it is the issue, what are my other options here if I can only connect via Directquery?
Hi siddrow ,
You can follow the below 3 options.
Option 1: Keep Logic Out of Composite Model (No Calculated Tables/Columns)
Avoid any calculated tables or columns that reference the DirectQuery dataset. Only create measures, and make sure those do not reference imported tables in their logic. Consider moving some transformations to Power Query (for import-mode tables).
Keep DirectQuery and Import parts completely decoupled (no relationship, no measure linking them).Option 2: Split into Two PBIX Files
This is the most stable and scalable option.PBIX 1 Live Dataset Model: Only connects to the shared DirectQuery dataset. Build all visuals and measures that rely on it. Publish it as a standalone Power BI report or dataset.
PBIX 2 Import Model: Connects to your other data sources. Create local measures and logic here.
In PBIX 2: Use Power BI datasets to connect to the published dataset from PBIX 1. This avoids calculated tables/columns issues because the entire remote dataset is treated as a semantic model, not raw tables.
Note: You can now reuse that dataset across multiple reports without hitting DirectQuery limitations.
Option 3: Use Dataflows as a Middle Layer
Useful if you want more control over the shared data or want to reuse across models. If the source data is available in a Power BI Dataflow , import that instead. You can schedule refreshes and shape the data in Power Query without relying on DirectQuery constraints. This gives you Import-mode flexibility, but still aligns with governance (if the dataflows are created in your organization’s workspace).If my response has resolved your query, please mark it as the Accepted Solution to assist others. Additionally, a 'Kudos' would be appreciated if you found my response helpful.
Thank you
