We were trying to change an existing Managed Metadata Site Column from allowing single values to allow multiple values. When we did so, we received this error:
/Lists/Projects : Cannot change this column to allow multiple values because it is
currently being indexed.
The error is a little bit misleading, as it might lead you to believe that the list is currently being indexed by search. (At least, that was what my client and I took it to mean.) In fact, the issue is that the column is indexed in the indicated list, which in this case was: /Lists/Projects.
I found a Microsoft KB article (2015261) which explained that “This itself is expected behavior.” The article applies to Microsoft Office SharePoint Portal Server 2003, but the same process fixes the issue in SharePoint 2010 (and therefore, I would expect in SharePoint 2007 as well).
By manually removing the index on the column in the Projects list, we were able to set the Site Column to allow multiple values. Note that multi-select columns in a list cannot be indexed in the list, so there’s a trade off. However, I’ve never had anyone explain clearly what difference adding an index to a list column gives us in the first place.
I think I’ve found an interesting (if you think things like this are interesting) difference between Document Libraries and Custom lists when it comes to the use of Site Columns. I had some filtering code in a DVWP that ought to have worked the same way on both a Custom List and a Document Library, but it turned out that the underlying column names in the Custom List were truncated but they weren’t in the Document Library.
Here’s what I mean. I added a Site Column called ‘Management and Administration’ to a Custom List and a Document Library. (I actually added it to a Content Type used by the Document Library and directly to the Custom List, but that turned out not to be the actual distinction.) The underlying column name in the Document Library ended up as @Management_x0020_and_x0020_Administration and in the Custom List it was @Management_x0020_and_x0020_Admin. This caused my filtering code not to work for the Custom List.
The simple workaround was to have two separate XSL templates for my filtering which were fundamentally identical, but took into account the slight difference in the column names. I ended up calling the two templates “ContentFilterDocLibs” and “ContentFilterLists” to make the distinction clear for future developers.
The truncation in Custom Lists always seems to happen at 20 characters, treating the space as a single character (not the 7 characters in the encoded _x0020_ string). I’m guessing that this is one of those little things that is still around from having had different sets of developers working on WSS vs. MOSS over the earlier versions of SharePoint.