Forum Discussion
Phantom ambiguous paths between tables causing issues
I think this is a bug in Power BI Desktop.
We have the below data model, with single-direction relationships between the offending tables.
If we create a table that links to Date Conversion and Ultimate Calendar, there is no issue, and they continue to filter the nameless table above, as before.
But if we try to activate the relationships between Date Conversion, and Ultimate Calendar, to FTE Numbers, we get the below error.
I have validated that both relationships from the Months table to Date Conversion and Ultimate Calendar, are indeed single-direction, but the model insists there are ambiguous paths going out of FTE Numbers.
Working solution, relationships to FTE Numbers deliberately kept inactive:
Erroneus Ambigious path, if those are activated and we try to again link Months to those tables above:
Even if I manually change the relationship to Many-to-Many, to allow for fine-tuning of direction of relationship, the same issue persists.
Consider this user error. We had two dates going to two different dates on the same table. The original model didn't have an issue as one of those relationships was many-to-many and the other a one-to-many, so the latter got prioritised and prevented the ambiguity error. Once we built identical types of relationships, the ambiguity came into effect.
3 Replies
Hi SevsBo
Did you use DAX to generate either calendar table? For example CalendarAuto?
There was a bug a few versions ago that causes the built in Calendar tables to clash with CalendarAuto.
If you are using CalendarAuto try using Calendar instead so Calendar(StartDate, LastDate). If that fixes the issue we know that was causing it!
Hi SamWiseOwl
We are already using CALENDAR, unfortunately.Worth mentioning that Date Conversion and most of the rest of this model comes from a direct link to a Semantic Model, but Ultimate Calendar, FTE Numbers and Months exist only in this report.
That said, Months is created entirely within this report, not from any external file.
Consider this user error. We had two dates going to two different dates on the same table. The original model didn't have an issue as one of those relationships was many-to-many and the other a one-to-many, so the latter got prioritised and prevented the ambiguity error. Once we built identical types of relationships, the ambiguity came into effect.
