SharePoint Internals: InternalName versus DisplayName
When creating columns (more commonly called fields) in SharePoint through the interface, you have to enter a name for it. This name is used throughout the lists and sites, included internally. Except when you try to change the name, it’ll only reflect on the outside. Internally the old name will be kept. This is because a field has two names: an internal name and a display name. When creating a field, you set both. When renaming it, you only change the display name. (There is actually no way to change the internal name afterwards)
But why is this a concern? Well, in the object model it can become quite vague when to use the internal name and when to use the display name. Here is a short list with some common methods and the name they need.
- SPFieldCollection[name] : SPField
name: DisplayName
unexistent: exception - SPFieldCollection.GetField(name) : SPField
name: internalName, displayName or internalName and displayName from the current context
unexistent: exception - SPFieldCollection.GetFieldByInternalName(name) : SPField
name: internalName
unexistent: exception - SPFieldCollection.ContainsField(name) : bool
name: displayName or internalName
unexistent: boolean - SPListItem[name] : object
name: internalName, displayName or internalName and displayName from the current context
unexistent: null - SPListItem.GetFormattedValue(name) : string
name: internalName, displayName or internalName and displayName from the current context
unexistent: exception
If I find more relevant functions, I will update this list. On a related note, there also exists a static name. This is a name used by the field type. This is different from the internal name, as the internal name must be unique in its list and could have changed.
Hope this clears up some confusion about field naming in SharePoint. See ya.
August 14th, 2008 at 12:14
[...] Bei der Programmierung bzw. bei der Verwendung des SharePoint Objekt-Modells muss man aber sehr aufpassen, welchen Spaltennamen man mit welcher Methode verwenden kann bzw. soll. Leider ist dies im SDK nicht einheitlich geregelt. Es gibt Methoden, bei denen schon aufgrund des Methodennamens klar ist, mit welchem Spaltennamen sie arbeiten: SPFieldCollection.GetFieldByInternalName(name) arbeitet wie der Name bereits andeutet, mit dem Internal-Name einer Spalte, während SPFieldCollection[name] den Display-Name verwendet. Bei SPListItem[name] wird die Sache noch etwas undurchsichtiger: hier sind alle drei Spaltennamen als Parameter erlaubt. Eine erste Übersicht von Methoden und deren Spalten-Parametern findet sich in diesem Blog. [...]
September 13th, 2008 at 12:56
[...] another SharePoint developer, has made a list with more examples here. He also details the inconsistencies around when an exception is thrown – yet another place to get [...]
July 1st, 2009 at 14:16
[...] Bei der Programmierung bzw. bei der Verwendung des SharePoint Objekt-Modells muss man aber sehr aufpassen, welchen Spaltennamen man mit welcher Methode verwenden kann bzw. soll. Leider ist dies im SDK nicht einheitlich geregelt. Es gibt Methoden, bei denen schon aufgrund des Methodennamens klar ist, mit welchem Spaltennamen sie arbeiten: SPFieldCollection.GetFieldByInternalName(name) arbeitet wie der Name bereits andeutet, mit dem Internal-Name einer Spalte, während SPFieldCollection[name] den Display-Name verwendet. Bei SPListItem[name] wird die Sache noch etwas undurchsichtiger: hier sind alle drei Spaltennamen als Parameter erlaubt. Eine erste Übersicht von Methoden und deren Spalten-Parametern findet sich in diesem Blog. [...]
October 14th, 2009 at 15:44
[...] Published October 14, 2009 IT Leave a Comment Tags: Sharepoint This blogpost describes the usage of the internalname vs. displayname problem in the Sharepoint object model, [...]
February 13th, 2010 at 18:31
Actually there are three different strings:
#1) Title/DisplayName
#2) StaticName
#3) InternalName
The InternalName of the list column instance is the real problematic one, as updates to the site column get pushed to the list column instance for both Title/DisplayName (which can be updated either via GUI or via feature redeployment), and for StaticName (which comes from the StaticName specified in the element XML of the feature), but while the site column’s InternalName can be updated from the feature (from the element XML’s “Name” attribute), the list column instance InternalName seems to be frozen forever.
As far as I can tell, this is a real bug in SharePoint 2007. I don’t know if they’ve addressed it in SharePoint 2010.
February 13th, 2010 at 22:45
The InternalName can only be set at creation time. It’s a bit like the Guid and should be seen as an identifier. One which can’t been changed. I don’t think it’s been changed in 2010, though.