Starting December 3, join live sessions with database experts and the Microsoft product team to learn just how easy it is to get started
Learn moreGet certified in Microsoft Fabric—for free! For a limited time, get a free DP-600 exam voucher to use by the end of 2024. Register now
I have run into an oddity that I cannot explain and hope someone in the community can explain the situation. My Power BI Desktop has the following items:
// SimpleFunction
let
result = ( ) => [ a = 1, b = 2, c = 3 ]
in
result
// ShowMyStuff
let
result = Table.SelectRows( Record.ToTable( #shared ), each not Text.Contains( [Name], "." ) )
in
result
// FindSimpleFunction
let
result = Table.SelectRows( ShowMyStuff, each [Value] = SimpleFunction )
in
result
// DoesReferenceMatch
let
result = #shared[SimpleFunction] = SimpleFunction
in
result
// ExecuteSharedReference
let
result = (#shared[SimpleFunction])( )
in
result
// InvokeSimpleFunction
let
result = SimpleFunction()
in
result
What I cannot explain, after searching the docs and googling, is why DoesReferenceMatch returns false, implying that the reference provided by #shared is not the same reference as SimpleFunction. However, when invoking the #shared reference it returns the same result as invoking SimpleFunction. It seems to me that what is returned by #shared is some sort of proxy for SimpleFunction.
Can someone point me to the docs or an article that explains this behavior of #shared? It would be handy, if the reference were the same, then a query like FindSimpleFunction would be able to return the textual name for a given reference value.
Solved! Go to Solution.
@ImkeF, that is an interesting observation about what #shared returns. In doing further research, I found that #sections can also be used and it does return the original function value:
#sections[Section1][SimpleFunction] = SimpleFunction
This brings up another question, why would Microsoft make the return values for #shared and #sections different!? Regardless, there are now two viable solutions for retrieving the textual name for a reference value and a possible explaination why #shared and #sections return differnet values. Thanks for sharing your observation.
Hi @houghtonap ,
I would be very carefull with that, as what you see in the query editor might not be the same than what is loaded into the data model or refreshed in the service.
You might want to test that thoroughly before using for actual work.
BTW: In a different file, I couldn't replicate the metadata behaviour. So if at all, I'd go for the Section function.
Very much agree that these functions should behave better 🙂
Imke Feldmann (The BIccountant)
If you liked my solution, please give it a thumbs up. And if I did answer your question, please mark this post as a solution. Thanks!
How to integrate M-code into your solution -- How to get your questions answered quickly -- How to provide sample data -- Check out more PBI- learning resources here -- Performance Tipps for M-queries
Hi @houghtonap ,
don't know if this is mentioned in the docs, but #shared handles the metadata differently, basically returning the metadata first.
So this will return true:
#shared[SimpleFunction] = Value.Metadata(SimpleFunction)
Imke Feldmann (The BIccountant)
If you liked my solution, please give it a thumbs up. And if I did answer your question, please mark this post as a solution. Thanks!
How to integrate M-code into your solution -- How to get your questions answered quickly -- How to provide sample data -- Check out more PBI- learning resources here -- Performance Tipps for M-queries
@ImkeF, that is an interesting observation about what #shared returns. In doing further research, I found that #sections can also be used and it does return the original function value:
#sections[Section1][SimpleFunction] = SimpleFunction
This brings up another question, why would Microsoft make the return values for #shared and #sections different!? Regardless, there are now two viable solutions for retrieving the textual name for a reference value and a possible explaination why #shared and #sections return differnet values. Thanks for sharing your observation.
Starting December 3, join live sessions with database experts and the Fabric product team to learn just how easy it is to get started.
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount! Early Bird pricing ends December 9th.
User | Count |
---|---|
35 | |
17 | |
12 | |
11 | |
9 |
User | Count |
---|---|
45 | |
27 | |
16 | |
14 | |
14 |