Using Display Names vs. Logical Names

[bfing]

I have a scenario where I ClearCollect data from a CDS entity so that I can use it locally within the app.  On a given screen, I have a Gallery to view the collection records, a Display Form to see selected record details, and an Edit Form to input/modify child record data of a related entity.  To drive the functionality, rather than using the Gallery.Selected identifier, I'm using a context variable defined as follows:

Gallery.OnSelect = UpdateContext({locCurrentItemRecord:ThisItem})

After setting up the screen and controls referencing Display Names (e.g. locCurrentItemRecord.Name, locCurrentItemRecord.Level, etc.) and getting the screen to function exactly as intended, I began to work elsewhere in the app.  When I came back to this screen, I saw an "Invalid Argument Type" error at each use of the context variable.  Specifically, the identified field name had the red underline and when you hover over it it says "This identifier isn't recognized".  When I changed the Display Name to the Logical Name, the error clears and the screen continues to function as it did previously.

I am curious what is triggering this change in operation of the screen and the previously functioning expressions?  My understanding is that there is mapping that occurs in the background that permits the use of Display Names.  Is this not the case with collections?  Should I proceed, when using collections, to simply reference the Logical Name the first time, so I don't have to go back and change this?

It may be worth noting that I'm supplementing the CDS data on the initial ClearCollect by using the AddColumns.  Thanks in advance.

[v-siky-msft]

Hi @bfing ,

I made a test on my side, both DisplayName and logical Name can be referenced correctly by variable.

Though I cannot reproduce your issue, I suggest you use Logical Name. When you go to Variables Tab to see the table stored in the variable, you can find all column names are Logical Name.

Hope this help.

Sik

[bfing]

I had already updated context variables to reference the Logical Names, as I mentioned.  I will continue to do so going forward, as you recommend.  However I'm still not clear on the why it worked previously using Display Names, and then had to be modified to Logical Names.

Thanks for the input.

[v-siky-msft]

Hi @bfing ,

It could be intermittent CDS connection problems.

Does this issue always come up?

Sik

[bfing]

Within my somewhat limit experience using PowerApps, I don't recall this happening, no. 

The first time it happened, I actually changed the context variable name in the few places it was defined, then in the several places it was used while keeping the Display Names.  This cleared all the errors initially.  But eventually (as in, clicking through the app and retesting all the functionality associated with the variable), all the same errors came back.  I also recall them not all coming back simultaneously, but rather 2 or 3 uses of the variable (that I corrected with Logical names) then another 2 or 3 uses a minute later (again correcting with the Logical Name).  Finally, I changed them all to the Logical Name so I could move on.  

Since I didn't understand why it was happening, I figured I would post the question.  Thanks again for the interest, let me know if you have any other questions.

[bfing]

Strangely, several more references to collection column Display Names broke again today (these were all previously working fine since before my original post on this thread).  This time however, they were not references to the collection columns through a record stored as a context variable; they were simply direct collection column references.

As before, changing to the Logical Name cleared the error.

Any feedback as to what may be triggering this change in Power Apps behavior is appreciated.

Thanks in advance.

[bfing]

Since I still don't have resolution on this item, I'll continue to document my experience in the event someone can properly explain why this is happening.

Today I made a small change to the data source that the collection and context variable reference.  When I subsequently opened the app, there were errors with all the controls that reference the collection and context variable.  Upon investigating further, the Logical Names that I previously had input had been revised back to Display Names.  I modified them back to Logical Names to clear the errors again.

[yichingjc]

@bfing @v-siky-msft I have a similar issue...

I've noticed the app would change the reference from schema name to display name. Whenever I opened the app it would somehow gives me error when referencing the display name so I changed to schema name. 

And now it somehow change itself back to display name and gives me the error.

[bfing]

Unfortunately, I stopped getting feedback on this post and I don't have a good understanding of why I was also experiencing these issues.  

For me, I simply stopped using Display Names when referencing fields from collections of cached records.  While this works, it was not the solution I looking for.  If you find a better solution or explanation, please share it here.

[Django]

Same happened to me last week... in my case a different user opened the Canvas App in his Studio and his references to the internal database name / logical name stopped working:

These are references to the Account table coming from the Common Data Model and our team did not change anything to the schema of this table.

My first thought was that it could be a browser language issue because referencing the language specific display name fixed the error:

However when my user account would open the Studio, the same errors appeared... while one week earlier that same user account (on the exact same device) would have no issues at all with this version of the Canvas App in the Studio referencing the logical names...

Still troubleshooting this one --> somehow it seems that Canvas App sometimes reference the display name and sometimes reference the logical name of Dataverse?