Monday, June 9, 2008

Be careful using non-alphanumeric field names in SharePoint

I found
that there are some inconsistency in internal name generating in WSS 3.0. I
encountered with it when receiving en error on checking in a file. SharePoint
log file did not reveal the problem as usual :) and I used my custom code to
troubleshoot. This is the exception description and a stack trace I received:

at Microsoft.SharePoint.SPFieldCollection.GetFieldByInternalName(String strName, Boolean bThrowException)
at Microsoft.SharePoint.SPFieldCollection.GetFieldByInternalName(String strName)
at Microsoft.SharePoint.SPListItem.get_MissingRequiredFields()
at Microsoft.SharePoint.ApplicationPages.Checkin.OnLoad(EventArgs e)

I
started to review code in Reflector and discovered that
SPListItem.MissingRequiredFields property is checked on page check in. For this
purpose it uses SPFieldLink.Name from SPListItem.ContentType.FieldLinks
collection to retrieve SPField object from SPListItem.ParentList.Fields
collection for every field which is SPFieldLink.Required=true. In order to get
SPField object SPFieldCollection.GetFieldByInternalName() method is used and if
SPFieldLink.Name field value is not found as internal name of any SPField then
we receive "Value does not fall within the expected range" exception.

In my
case I have a field named "Description of Change/New document" which is
translated to internal name as
"Description_x0020_of_x0020_Change_x002F_New_x0020_Document" but for some reason
SPFieldLink.Name field value for this field is
"Description_x0020_of_x0020_Change_x002f_New_x0020_Document". Feel the
difference in unicode of symbol "/": x002f (small 'f') and x002F (capital 'F').
That gives me two different internal names and I have these troubles. I guess
there is inconsistency and there are several functions which generate internal
name and these functions produce different result in some cases.

When I
recreated my field the problem was fixed for which I do not have any
explanation.