Forum Discussion
Relationship between calculated table and Direct Query table not recognized
I'm trying to return TRUE/FALSE based on whether there is a matching row in a related table, and I'm encountering problems.
There is a fact table in my Direct Query data source:
Stores ISP (ProductID, SubsidiaryID, SnapshotDate, StoresReplenish, more)
There are two dim tables in my Direct Query data source:
Product (ProductID, SKU, more)
Subsidiary (SubsidiaryID, Subsidiary, more)
I have two calculated tables:
ReplenishAll =
DISTINCT (
SELECTCOLUMNS (
'Stores ISP',
"ProductID", [ProductID],
"SubsidiaryID", [SubsidiaryID],
"Concat", CONCATENATE ( [ProductID],[SubsidiaryID] )
)
)
ReplenishOnly =
DISTINCT (
SELECTCOLUMNS (
FILTER (
'Stores ISP',
'Stores ISP'[Stores Replenish] > 0
&& 'Stores ISP'[SnapshotDate] > TODAY () - 8
),
"ProductID", 'Stores ISP'[ProductID],
"SubsidiaryID", 'Stores ISP'[SubsidiaryID],
"Concat", CONCATENATE ( [ProductID],[SubsidiaryID] )
)
)
I created an active one-to-one relationship between the two tables on [Concat].
I created a third table:
Replenishable =
ADDCOLUMNS (
ReplenishAll,
"Replenish", NOT ( ISBLANK ( RELATED ( 'ReplenishOnly'[Concat] ) ) )
)I created active many-to-one relationships between Replenishable & Product and Replenishable & Subsidiary on the appropriate ID fields.
However, these relationships don't seem to be working. When I put replenish in a slicer, filtering a matrix that includes fields from Product and Subsidiary, it doesn't actually filter the matrix. When I double checked the relationships by using NATURALINNERJOIN ( 'Replenishable', 'Product' ) I got an error saying there were no column join columns detected.
Here's a screenshot showing the active relationship:
Why is the relationship I created not working? How can I fix it?
I have discovered that relationships are broken in some way between Direct Query tables and calculated tables, so I am unable to use the calculated table measure as a slicer to filter Direct Query data in the visuals.
While it is possible that converting or duplicating some of the Direct Query tables to Import mode would solve the broken relationship issue, the underlying problem I was trying to solve was to highlight SKU&Subsidiaries incorrectly marked as not replenishable. Since I am having so much trouble with the slicer, I have decided to focus on the more correct solution to this underlying problem, which is to work with the upstream data support teams to fix the source data.
8 Replies
I have discovered that relationships are broken in some way between Direct Query tables and calculated tables, so I am unable to use the calculated table measure as a slicer to filter Direct Query data in the visuals.
While it is possible that converting or duplicating some of the Direct Query tables to Import mode would solve the broken relationship issue, the underlying problem I was trying to solve was to highlight SKU&Subsidiaries incorrectly marked as not replenishable. Since I am having so much trouble with the slicer, I have decided to focus on the more correct solution to this underlying problem, which is to work with the upstream data support teams to fix the source data.
Hi shadowsong42,
Thank you for reaching out to the Microsoft Fabric Forum Community.
Based on your setup, it appears the problem stems from how filter context is being handled between your calculated tables and DirectQuery-based dimension tables. Relying on a concatenated key (Concat) and using RELATED () in this scenario can lead to inconsistent filter propagation especially when expecting slicer interactions to flow through these custom relationships.
Try moving away from using a calculated column to determine the replenishment flag and instead implementing a DAX measure that dynamically evaluates replenishment status based on your original Stores ISP fact table.
Is Replenishable = CALCULATE ( COUNTROWS ( 'Stores ISP' ), 'Stores ISP'[Stores Replenish] > 0, 'Stores ISP'[SnapshotDate] > TODAY() - 8 ) > 0can be used to determine whether a given ProductID and SubsidiaryID pair had replenishment activity in the past 7 days. Since your fact table already has relationships with the Product and Subsidiary dimension tables, this measure will respect existing relationships and propagate correctly in your visuals.
This approach avoids the limitations of calculated tables in composite models and ensures that slicers and visuals interact as expected.
If this post helps, then please give us ‘Kudos’ and consider Accept it as a solution to help the other members find it more quickly.
Thank you.
I was originally using a calculated measure! Unfortunately, my goal is to use the Replenishable field in a slicer, which I can't do with a calculated measure. Is there a way to generate this value that will return TRUE/FALSE and can be used in a slicer?
Hi shadowsong42,
Thanks for the clarification—that makes your goal crystal clear. Since you’re aiming to use a Replenishable field in a slicer, a calculated measure won’t work, as slicers only operate on columns, not dynamic measures. You're absolutely right to pivot toward a solution that gives you a TRUE/FALSE value as a column, while still working within the constraints of your composite model and Direct Query setup.
A reliable way to achieve this is to create a calculated table that builds the Replenishable status based on actual (ProductID, SubsidiaryID) key combinations from your fact table. Instead of relying on concatenated keys or RELATED(), which can cause filter propagation issues in composite models, you can use LOOKUPVALUE() to directly check whether a given combination appears in your filtered set. This ensures compatibility with slicers and avoids the inconsistency you're seeing.
Replenishable = SUMMARIZE( ReplenishAll, ReplenishAll[ProductID], ReplenishAll[SubsidiaryID], "Replenish", IF( NOT ISBLANK( LOOKUPVALUE( ReplenishOnly[ProductID], ReplenishOnly[ProductID], ReplenishAll[ProductID], ReplenishOnly[SubsidiaryID], ReplenishAll[SubsidiaryID] ) ), TRUE, FALSE ) )If this post helps, then please give us ‘Kudos’ and consider Accept it as a solution to help the other members find it more quickly.
Thank you.
