Quantcast
Channel: SharePoint Internals - Hristo Pavlov's Blog
Viewing all articles
Browse latest Browse all 10

The column name that you entered is already in use or reserved. Choose another name.

$
0
0

This is an annoying one. SharePoint will not allow you to create a site column from the UI (using the _layouts/fldnew.aspx page) if the name of the column is one of:

constructor, concat, join, pop, push, reverse, shift, slice, sort, splice or unshift

even if these site columns do not exist in the SharePoint site. If you try to create one of these fields you will get an error message saying that:

The column name that you entered is already in use or reserved. Choose another name.

Hmmm … Well after investigating this one it turned out to be a genuine bug caused by a JavaScript artifact. The way the fldnew.aspx page checks at the client side if a column already exists is by having all existing columns stored in a JavaScript Array called g_FieldName and then checking if the column that user tries to create is already in the array. This is done by the following code:

g_FieldName["E-Mail".toLowerCase()] = 1;

 

g_FieldName["Type".toLowerCase()] = 1;

function doesFieldNameConflict( strName )

{

      if(g_FieldName[strName.toLowerCase()])

            return true;

      else

            return true;

}

The problem with this code is that for some unknown to me reason which is probably related to the way the JavaScript VM is implemented, if you create a new Array called arr and then try to read arr["shift"] for example, this will return the following string:

 shift

And this happens on both Internet Explorer and Firefox. And this will happen for all strings that are names of methods of the JavaScript Array object and this is case sensitive. Because SharePoint does the check in lower case, then only the methods that are entirely in lower case will be a problem and the list of SharePoint site columns you won’t be able to create from the UI given at the top is the list of all methods of the Array object that are fully lower case.

So how to get around this. Well first of all this is a bug that should be resolved by Microsoft. They could either store everything in upper case (no JavaScript methods are fully upper case) or can change the function to

function doesFieldNameConflict( strName )

{

      if(g_FieldName[strName.toLowerCase()] == 1)

            return true;

      else

            return true;

}

The problem with the first function is that g_FieldName[strName.toLowerCase()] will be evaluated to true for anything which is not 0, false, null or unknown. In the case of arr["shift"] it will return the string shown on the screen-shot above, which will be evaluated to “true”. So explicitly testing for “1″ will resolve the bug.

In the meantime if you need to create a site column with one of those names you could do it using code or features. And if you wonder how I discovered this issue – well I wanted to create a site column called “Shift” as in work shift which I consider as a totally legitimate use case.



Viewing all articles
Browse latest Browse all 10

Trending Articles