RELATED() "relationship doesnt exist" even though it does

[alldaydata]

Hi all,

I have two tables, say TBL_MANY and TBL_ONE.

There exists a many to one relationship, which is active and cross filter is defined both ways.

Filtering from the one to the other works in the report page.

However, when I create a rather trivial new calculated column in TBL_MANY:

= RELATED(TBL_ONE[someColumn])

I get the error message back "The column xxxxx either doesn't exist or doesn't have a relationship to any table available in the current context."

I want to stress that intellisense does suggest the TBL_ONE and associated columns for autocompletion of RELATED( , so it appears indeed the relationship is recognized (just like "RELATEDTABLE(" properly autocompletes when I create a calculated column in TABLE_ONE, just as expected...).

Am I missing something mundain here?

thanks in advance!

[MattAllington]

No your not missing anything about the functions. It should work. Try deleting the relationship and set it to single filter direction. Then try again. Moreover, in my experience, when people use related, they are often trying to do something that can be done a better way. There is no need to add a column in the many table as that is what the relationship is for. 

[alldaydata]

Hi Matt,

thanks for the quick reply!

I tried that (delete entirely and reconnect + single direction), including disactivating and re-activating, but to no avail. Do you think this might be a bug? I just installed a new PBI version (64 bit) only yesterday...

I understand this trivial example makes no sense, but its what I ended up with while debugging. In reality I use RELATED() in a measure where I select rows in TBL_MANY in row context before aggregation, based on some criterium using variables in both tables.

[Anonymous]

Can you please put a file with this issue somewhere on a cloud drive (OneDrive, Google Drive, Dropbox) and post a link to it? When doing it, please set the right read permissions.

Thanks.

Best

Darek

[alldaydata]

I would (have), but my data is sensitive. I also cannot replicate the problem from two simple test tables with manual input, even though I see no difference with my case. I'll see if I can trim down and/or map out the senistive stuff while still keeping the problem.