Please be so kind as to read my full post before responding.
Thank you for your consideration.
I have recently noticed that I required the global disambiguation operator @ in more places than I used to require it.
In particular, it now seems to be required for referencing my Data Sources in places it was not needed before.
Some parts of older code needed me to add this to work in newer PowerApps releases.
My last test with this was done using
Session ID: c3f74df3-269c-4924-8e33-9adbcc515534
Two examples, where I could previously directly use
without the disambiguation operator @ , but which are currently only working with it, are:
To give you a more complete picture, please be aware that the entity in question also might appear as LookUp in other entities in the same PowerApp(s).
Here are two screenshots of the (working versions) with disambiguation for the Data Sources where earlier versions didn't require disambiguation.
The first case without disambiguation yields an underlined error.
The second case without disambiguation yields an empty result/nothing.
Do you have a local and remote source with the same/similar name that then requires disambiguation?
Please 'Mark as Solution' if someone's post answered your question and always 'Thumbs Up' the posts you like or that helped you!
No, there are no tables, collections, variables, or DataSources with the same name.
The only thing coming to mind with really the same (plural name) "PowerFair-Leads" are the new Relational Data Fields in the entities that my custom entity "PowerFair-Lead" contains lookup fields to.
The thing with DataSourceInfo appears to be specific to this one entity in this one App.
For better or worse, I now always use disambiguation for my data sources as this always works.
This is only a minimal inconvenience.