DirectQuery to AAS: Measures return Blank instead of Error after Refresh (Silent Failure?)

[WangHsuanHui]

I am encountering a strange issue regarding Power BI Service connectivity with AAS involving Composite Models and measure dependencies. Has anyone experienced something similar?

1. Architecture Background:

• Connection Mode: DirectQuery to Azure Analysis Services (AAS).
• Composite Model: It includes a local DAX-calculated table 'D_Calendar' and the original table 'D_Calendar 2' from the AAS side.
• Capacity Details:
  • AAS Pricing Tier: S2
  • Microsoft Fabric Capacity: F64
• Measure Logic: Due to model complexity, I created a series of report-level measures displayed in the same Matrix visual
  1. Measure A (Base): Uses multiple TREATAS functions to establish virtual relationships across various dimensions (e.g., Product, Store, etc.). Crucially, one of the TREATAS expressions maps the remote AAS date table to the local DAX table as follows:

TREATAS(
    SUMMARIZE('D_Calendar 2',
        'D_Calendar 2'[DateKey],
        'D_Calendar 2'[YearMonth]
    ),
    D_Calendar[DateKey],
    D_Calendar[YearMonth]
)

1. Measure B : DIVIDE([Measure_from_AAS], [Measure A], 0).
2. Measure C (Last Year): CALCULATE([Measure A], DATEADD('D_Calendar 2'[Date], -1, YEAR)).
3. Measure D (Last Year YTD): Applies YTD filtering based on Measure C.

2. The Issue:

• Desktop: Everything displays correctly.
• Service (Initial Publish): Displays correctly immediately after publishing.
• Service (After Scheduled Refresh): After a Scheduled Refresh runs in the Service, [Measure C] and [Measure D] suddenly return BLANK.

3. Cross-Testing Findings (Crucial):

While the issue was occurring in the Service, I tested the fields in the Matrix visual:

• If I remove [Measure B]: The values for [Measure C] and [Measure D] instantly reappear and display correctly.
• If I add [Measure B] back: [Measure C] and [Measure D] immediately return to BLANK.

Previously, I encountered QuerySystemError (Memory Limit exceeded) with this exact Matrix visual. The cause was identified as excessive data volume/filtering straining DirectQuery performance. I have since reduced the data scope, and I no longer receive any explicit MemoryLimit or QuerySystemError messages.

However, now instead of an error message, the visual simply renders BLANK values for specific measures. I am unsure if this indicates a change in the backend mechanism (silent failure instead of throwing an error) or purely a metadata/lineage issue.

I suspect that the combination of TREATAS and DIVIDE is causing a break in Metadata/Data Lineage within the Query Plan after the cloud refresh/update, which subsequently affects the DATEADD calculation in the same visual.

Is this a known limitation of DirectQuery? Is there a permanent solution/workaround other than constantly re-publishing the report to force a metadata sync?

Thanks in advance!

[v-veshwara-msft]

Hi @WangHsuanHui ,

Just checking in to see if you query is resolved and if any responses were helpful.
Otherwise, feel free to reach out for further assistance.

Thank you.

[Poojara_D12]

Hi @WangHsuanHui 

This is a lines up with a real limitation in Composite Models + DirectQuery to AAS, not a random bug or something you’re mis-configuring. In short: after a Service refresh, the query plan generated in the cloud changes, and the combination of TREATAS across local and remote tables + a dependent DIVIDE measure in the same visual pushes the engine into an unstable state. In Desktop and immediately after publish, the engine still has a “clean” metadata lineage and the measures resolve correctly. After a scheduled refresh, the Service rehydrates the model and recompiles the DirectQuery plans, and at that point the optimizer can no longer safely reconcile the lineage between the local calendar table and the remote AAS calendar when those measures are evaluated together. Instead of throwing a hard error (like the memory errors you saw earlier), the engine now fails soft and returns BLANK for downstream time-intelligence measures such as DATEADD and YTD. The fact that removing Measure B instantly restores Measure C and D is the smoking gun: it forces a simpler query plan and avoids the lineage conflict caused by mixing DIVIDE, virtual relationships, and time intelligence over split models. This is not something a republish truly “fixes”; republishing just resets the metadata cache temporarily. The durable workarounds are architectural: avoid using DATEADD/YTD over a remote date table when the filter context is established via TREATAS from a local table; push the calendar logic fully into AAS (preferred), or fully localize it and avoid cross-engine time intelligence; alternatively, materialize the virtual relationship logic into a single base measure or calculation group so it isn’t recomputed per visual. Unfortunately, this is a known edge-case behavior of DirectQuery composite models in the Service, and today there is no guaranteed fix other than restructuring the model to reduce cross-engine lineage dependencies.

[WangHsuanHui]

Hi @rohit1991  ,

Thank you for reply soon!

Since this "known DirectQuery limitation" is rarely documented explicitly in the official Microsoft documentation, I would love to learn more about where this knowledge comes from. I am trying to improve my own ability to troubleshoot these types of backend limitations. Could you share what key reading materials, or technical blogs led you to this conclusion?

[WangHsuanHui]

Additionally, regarding the MeasureB formula you provided, does this imply that for DIVIDE() to "explicitly guard" the measure and prevent a collapse, the underlying mechanism is effectively forced to act like an IF() statement? In other words, when the model hits its performance limit, does it return a BLANK as a protection mechanism instead of throwing a MemoryLimit? Is this "silent blank" is actually a sign of insufficient hardware resources on the AS side?

Thanks again for sharing your expertise!

[WangHsuanHui]

Hi @rohit1991 ,

Thanks for reply me soon!

Since this "known DirectQuery limitation" is rarely documented explicitly in the official Microsoft documentation, I would love to learn more about where this knowledge comes from.

I am trying to improve my own ability to troubleshoot these types of backend limitations. Could you share what key reading materials, or technical blogs led you to this conclusion?

Additionally, regarding the Measure B formula you provided: 

Measure B :=
IF (
    NOT ISBLANK ( [Measure_from_AAS] ),
    DIVIDE ( [Measure_from_AAS], [Measure_A] )
)

Does this imply that for DIVIDE() to "explicitly guard" the measure and prevent a collapse, the underlying mechanism is effectively forced to act like an IF() statement? In other words, when the model hits its performance limit, does it return a BLANK as a protection mechanism instead of throwing a MemoryLimit?

Is this "silent blank" actually a sign of insufficient hardware resources on the AS side.

Thanks again for sharing your expertise!

[v-veshwara-msft]

Hi @WangHsuanHui ,

Thank you for the follow up.

The earlier explanation by @rohit1991 is directionally correct.

Microsoft documentation confirms that DirectQuery and composite models have limitations and that query execution in the Service can differ from Desktop due to optimization and planning differences. In complex composite scenarios, results after a scheduled refresh may not always behave consistently.

DirectQuery in Power BI: When to Use, Limitations, Alternatives - Power BI | Microsoft Learn

Use composite models in Power BI Desktop - Power BI | Microsoft Learn

The guarded DIVIDE pattern does not change the internal behavior of DIVIDE, but it can alter the query evaluation path and reduce dependency chaining, which may avoid unstable query plans in some DirectQuery scenarios. This should be considered a mitigation rather than a guaranteed fix.

There are also community discussions that describe how caching and metadata handling can affect composite model behavior in the Service, particularly after refresh.

For example: Solved: Composite model - not able to refresh when I have ... - Microsoft Fabric Community

Hope this helps. Please reach out for further assistance.
Thank you.

[v-veshwara-msft]

Hi @WangHsuanHui ,

Just wanted to check if the response provided was helpful. If further assistance is needed, please reach out.
Thank you.

[rohit1991]

Hii @WangHsuanHui 

In DirectQuery to Azure Analysis Services composite models, measures may return BLANK after Service refresh when virtual relationships (TREATAS) and remote measure dependencies are involved. After refresh, Power BI may fail to re-bind the query lineage and silently returns BLANK instead of throwing an error. This is a known DirectQuery limitation, not a DAX issue. A common mitigation is to guard remote measures explicitly so downstream calculations do not collapse.

Measure B :=
IF (
    NOT ISBLANK ( [Measure_from_AAS] ),
    DIVIDE ( [Measure_from_AAS], [Measure_A] )
)