For the longest time I was trying to figure out the relationship between Display Name, Internal Name, and Static Name in SharePoint. While Display Name and Internal Name were fairly easy to understand for me, the function of the Static Name eluded me for the longest time. If you have been reading my blogs, you probably know that I can’t stand using something that I have no complete understanding of. I kept bugging me, so finally I said “enough is enough” and embarked on a little investigation. Here are the results of this investigation:
SharePoint Services 3.0 SDK Help has explains these fields away (these are properties of the SPField class):
Title a.k.a. Display Name: A string that contains the display name.
Internal Name: Gets the internal name that is used for the field.
Static Name: Gets or sets the internal name of the field.
Based on these descriptions, one would think that Display Name is the name shown to the user, while Internal Name and Static Name are the same thing except that Internal Name is read-only while Static Name is read/write. Anybody who has done work in SharePoint knows that this is not the case. While Static Name and Internal Name are often identical, they are not always the same.
So what’s the deal with them?
Display Name is the name shown to the user. It can contain spaces in special characters. When display name is created, an Internal Name is derived from it by replacing spaces and special characters with _0xXXXX_ where XXXX is a Unicode hexadecimal representation of the character being replaced. For example: My Column Name would be converted to My_0x0020_Column_0x0020_Name. Once the Internal Name is set it cannot be changed even if the Display Name from which it is derived is changed.
Now, this seems straightforward, but what is the difference between the Internal Name and Static Name? Intuitively, they seem to have to be the same. In order to understand what these properties really are it is important to keep in mind that SPField class is used in a number collections under a number of circumstances. For example:
· SPField could represent a Site Column in SPWeb.Fields collection
· SPField could represent a Site Column that is part of a Content Type (inside SPContentType.Fields).
· SPField could represent a column in a list that is coming from a site column (inside SPList.Field).
· SPField could represent a column in a list that is coming from a content type(inside SPList.Field).
· SPField could represent a column in a list that has been created directly in that list (inside SPList.Field).
· etc.
All of these collections use the same item type (SPField or its derived classes: SPFieldLookup, SPFieldChoice, etc).
While Display Name, Internal Name, and Static Name are often the same, let take a look at a scenario where they might be different. After following that scenario, the function of each of these properties will become clear.
Let’s say we created a custom list LST in SharePoint that contains column named A. Then we created a site column named A and then we created a content type CT that contains our site column A. Now, if we enable the content type CT for our list LST, we end up with a list that has two columns named A. Obviously they need to be referenced differently (at least internally). That is why, when SharePoint provisions a new column on a list while another column with the same name already exists in the list, SharePoint adds a digit to the Internal Name (keep in mind that the Internal Name is the one used to reference columns in the list). For example, in our case we would end up with a column A and a column A0. If we were to add another one, it would be A1, etc. When a column is provisioned like that and its Internal Name is changed, Static name remains the same (so is the Display Name but that is beside the point).
Therefore, the true definition for these fields should be:
Title a.k.a. Display Name: A string that contains the display name. Display name is used to derive Internal and Static Names, however once those are set, changing Display Name will not affect Internal and Static Names.
Internal Name: Gets the internal name that is used for the field. It is a unique non-changeable string that identifies a column in the list. If multiple columns in the list have the same name, SharePoint will add 0,1,2,etc at the end of each new column added to make them unique.
Static Name: Gets or sets the internal name of the field. This is the internal name of the fields “as God intended it” without any digits added to it. It is not guaranteed to be unique within a list.
As always, if you see any mistakes or inaccuracies in this blog, please let me know.
I know this is an old post – but still very relevant. I just got bit by this in one app where I was using StaticName to do queries when really I should be using Name instead.
Thanks for posting.
Thank you for posting! I just got confused by these and found your explanation.
I think my issue is related to this, but not sure. I have existing calendar lists(customized) that use a type = InventoryEvent.
I needed to create another calendar, but the template function although it copied the basics of the list for some reason did not allow the 2013 workflows to copy.
After having manually done all of those (and they are very complicated. used more for back end logic than true workflow) I was doing some testing.
I have a display field which calculates a total on a set of fields. Lets say they are crewA crewB crewC.
I noticed the display field is missing crewC in it’s total.
I then reviewed the display form for NewList vs one for OldList. NewList shows crewC as @CrewC2 while old list shows it as @CrewC.
I don’t want to even attempt to change the display calculation on the new list. I want things consistent so nothing comes back to bite me later.
What happened? I haven’t manipulated that field in this list, and it appears to be working normally as CrewC in all the other lists.
Is there a way to force this field to be CrewC in NewList?