Forum Discussion
Responsive ResidentExpression.Evaluate object does not exist in the current context
Community ChampionThanks for the workaround :smileyhappy:
There is some explanation in chapter 11 of the - very technical document - Power Query M Language specification.
It explains why objects may or may not be available in different contexts.
It refers to #shared and #sections. According to the information, it should be possible to define sections yourself, but that is not possible via the Power Query User Interface in Power BI / Excel.
On page 7 of the same document, point 10 states:
"Sections provide a simple modularity mechanism. (Sections are not yet leveraged by Power Query.) "
My interpretation was that you can only refer to your own objects in the Query Editor environment (via =#shared or via =#sections[Section1]) and not outside the Query Editor.
Your workaround is a change of view for me, so thanks again.
Responsive ResidentThanks Marcel, it's great to get some dialog on this and thanks also for your insights regarding the spec. To be honest, I found the syntax of that document impossible to understand but, I might re-visit that now that I have a better idea what's going on.
My view on the #shared intrinsic variable is that this is like a scope object or pointers in the call stack, or an execution context…, and that the PQ engine will try it's best to optimise (minimise) memory use in this object (including objects referenced by it). So the PQ engine will manage the membership of the #shared object based on references it sees in the code.
It seems like the optimisation decisions are different in the Query Editor and the Visual, the latter being more aggressive, but it could be that the QE environment keeps references to all objects, as you would expect for a development environment, and that the visual environment does not. Therefore, the underlying engine does not include unreferenced objects in the current context and that's why I to this work-around.
But anyway, it (the work-around) was nice to find. It was a great moment after too many hours muddling about in the dark. :Q
By the way, do you have any other way to reference a table by name? That's why I fell down this rabbit hole in the first place. Thinking about it now, I guess I could use
myTable = Record.Field(#shared, tableName)
Provided of course the above referencing considerations are satisfied...
v-chuncz-msftCommunity Support
Query Dependencies view in the Query Editor (under the View tab in the ribbon) allows you to see all queries and your dependencies on other queries or data sources at a glance, as well as an indicator of their Load status.