Strange Error when using DropColumns

[JR-BejeweledOne]

I have an in app collection that has columns for an ID, ShowSave and ShowEdit to allow manipulation of edit and remove icons for the rows in a gallery.

In order to collect this, I need to drop the 3 columns that don't exist in the permanent data source.

This works:

Both collections showing the Country column.  This is important!

HolidayCollection

TempHolidaySchedules

Error (What the Heck?):

Can anyone tell me what is going on here and how to fix it?

@RandyHayes

@mdevaney 

[RandyHayes]

@JR-BejeweledOne 

Yes, this is a collision of schema elements.  Happens often when trying to do everything with collections as they have to infer their schemas from the other.  If you already have the HolidaysSchedule collection established, then it is unable to narrow the inference of the schema.

I would look at how you are using the collection in other places first.

[JR-BejeweledOne]

HolidaySchedules is the dataverse table, not a collection and ShowSave, ShowEdit and CollID do not exist in the table.   Holiday Collection and TempHolidaySchedules are collections.

[RandyHayes · Accepted solution]

@JR-BejeweledOne 

Thanks for the clarification.  Then the issue is a naming issue.  Your collection TempHolidaySchedule needs to have the EXACT "real" name of the columns in it.  I would take a look at your Country column in your dataverse table and see what the real name is and make sure your collection has a column with that name.

The error message is misleading as it is for one, trying to find the exact name, but then tells you the closest name based on the "not real" name.

But check that column real name and make sure you have that in your collection properly.

[JR-BejeweledOne]

I have to admit that it absolutely drives me nuts that MS allows 'display' names vs 'real' names and in many cases allows you to use them interchangeably and in some cases, i.e. a renamed SP title column, wants you to use the 'Display name' and won't even let you use the 'Real name', but in other cases requires you to use the 'Real Name'.

It's incredibly confusing.

[RandyHayes]

@JR-BejeweledOne 

Yes, it really depends on the nature of the function.  In your case, you are attempting a bulk update to the datasource, so having the names completely match in the records is important to not having the function alter them as it goes.  Not only would that slow it down, but also potentially cause some delegation issues.

To be honest, I sort of wished that they didn't support anything but the real names.  I know that would make the app very confusing to "read" if you happened to have changed a column name, but to be honest, if I need to change a column name (other than Title), I usually delete the column and create a new one that is named the way that I want.  

However, for functions that do support "renamed" names, you can also specify the real name itself.  Example, if you rename an SP Title column to "Employee", you can use either of the following formulas:

  LookUp(spList, ID=1, Employee)   OR   LookUp(spList, ID=1, Title)

They will both show the same results.  The only real difference is that the "intellisense" in the formula editor will not show Title as an option.

You used to be able to turn this ability on and off in the app, but it seems that feature is long gone.