I ran into a situation with some custom InfoPath Document Information Panels where I was getting schema validation errors like this one because of a Business Data Column I added to a document library:

“…{guid}ColumnName is unexpected according to content model of parent element ‘documentManagement’.”

You might run into this in the following situation:

1. You create the DIP on a Site Content Type.
2. You configure a document library to use your Site Content Type.
3. You add a custom column to the Document Library (and subsequently to the List Content Type (the local instance of your site content type that is applied to the list)).

In this situation, your Document Information Panel was created without the knowledge of this extra column, and does not have a field in its data source schema for this column. What I believe is happening is that when attempting to view the DIP, SharePoint is passing all the columns on the document library to the InfoPath form, and the form is not expecting this extra column, so it chokes (very lame, Microsoft).

To get around this:

1. Edit the DIP on the List Content Type (List Settings, click content type name, Document Information Panel Settings, Edit this Template link)
2. Once the form loads in InfoPath, choose Tools > Convert Main Data Source…
3. Enter the absolute url to your document library (e.g. http://yoursitecollection/subsite/your doc library name), and click Next.
4. Finish the wizard and view your Data Source. Expand the nodes and you should see the extra list column appear now.

This is also a great way to update the DIP on your List Content Type, especially if you have locally overridden the Optional/Required/Hidden settings on columns from the parent Site Content Type.

This workaround kind of defeats the whole point of setting the Panel at the Site Content Type level, but that’s the only way I could get it to work.

Tags: Document Information Panel, InfoPath, SharePoint

I had the need to set Business Data and other column values in the ItemAdding event handler. I had to use ItemAdding, because I needed the changes committed so that the values I set would be visible on the Edit Properties screen immediately after uploading a document. Using the synchronous handler guaranteed that the values would be set.

I ran into the following issues with ItemAdding/ItemAdded event handlers:

• Setting AfterProperties for some columns was not working using the InternalName of the field.
• For Microsoft Office document file types, any data that I set in ItemAdding event via AfterProperties was lost after the first time the item was edited.

According to other people’s experience, when using the AfterProperties in ItemAdding event, you must use the Internal Name of the field, not the display name.

When I did this, however, my experience was exactly the opposite. It was only by using the Display Name of the field that I could actually get any of the data to stick. I’m not sure if it was my particular mix of SP1, Site Content types, 64bit server, and the use of a Business Data column on the document library that was making it not work, but I simply had to use the display name, or else none of the data I set would stick (my column names had a mix of spaces and no spaces, and interestingly the column names with no spaces worked either way).

This whole architecture of hashtables of properties and trying to match up values seems to me to be pretty fragile, and I’m not sure why Microsoft went this way. It also seemed to create my second problem, where data I did set disappeared.

Once I got things working with the Display Name of the field, I then noticed that I had a problem with the data disappearing after I would edit the properties of the document. But this was only for Microsoft Office document types, things were fine for image files, text files, xml files. In debugging, I checked the values at ItemAdding, ItemAdded, ItemUpdating, and ItemUpdated. Everything looked as it should through ItemUpdating, but somewhere in between ItemUpdating and ItemUpdated, the data was lost, and my values were set to empty strings. It seems there is something strange with the parser for Office file types.

To get around this, I had to set the values again in the ItemAdded event and Update the ListItem.

I would have simply switched to using ItemAdded exclusively, since that seemed to retain the data in all cases, but my code was executing a call to the Business Data Catalog, and so was a little slow. This would cause errors from SharePoint when a user would change data in the Edit Properties screen after upload, because it would complain that the file was recently updated. Generally a problem I would expect from an asynchronous handler.

To solve this, I do the heavy lifting code in ItemAdding, and then simply do a resetting of the value in ItemAdded to ensure that it sticks.

I still don’t feel comfortable using ItemAdded for this, but it seems to be fast enough that I don’t have any problems.

Tags: SharePoint

I got this recipe for a solution to cleaning moldy walls, like my concrete block garage walls currently are.

• 1 5 gallon bucket
• 4 gallons hot water
• 1 cup TSP
• 1 cup bleach
• 1 cup pinesol

Mix and then scrub the walls. Then they’ll be ready for paint.