Expression.Evaluate object does not exist in the current context

[RobertSlattery]

I have an unanswered question on a similar issue but I am re-posting here with the more fundamental root cause hoping it will attract an answer.

My problem is that the #shared record as evaluated in the Query Edit window is different from the value it has in the visual.

My minimum working example uses this function…

let

     export = (fy as list) =>

       let

           ret = List.Transform(fy, each

                   #shared

           )

       in

           ret

in

   export

All I am doing is iterating over a List and recording the value of the #shared record inside the iterator function.

When I call this from a query and navigate to the first record, I see the #shared object and it includes all of my global tables.

 When I evaluate the same query in a visual, all I see is the table being executed.

 

Am I missing something? I don't understand why the context should be different. To me, it seems like a bug that the only global Tables exposed is the current one.

EDIT

I did find a work-arround which is to have a query that touches all of the tables you want exposed and include that in your host query.  It seems that, in the visual, the scope is dynamically adjusted acording to what is referenced.  And this is different in the Query Edit environment.  I kinda get why but anyway Booo.

REMINDER

File/Optoions and settings/Options/Current File/Privacy/Ignore Privacy levels and ...

[MarcelBeug]

Thanks for the workaround

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.

[RobertSlattery]

Thanks 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-msft]

@RobertSlattery,

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.