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.
I am really happy that I found this blog because I thought this is a very unique case.
However, I am only experiencing the problem only for Office 2007 documents (.docx, .xlsx, .pptx) types. I tried to implement your solution and still the metadata won’t stick.
Hey rgarcia,
At this point, I’m not sure what I can recommend, other than a support incident with Microsoft.
What you could try is to store your metadata as a string of xml somewhere (like the spweb.properties bag). Then in ItemUpdated try to check if your metadata is missing, and if it is, read back the data and update the fields, and then clear out the properties bag entry.
For me, the metadata would disappear only the first time the item was edited. After that, the metadata would stick from that point on.
Have your aspirin bottle nearby.
Adam, great blog. I had the exact same problem and your solution solved it. Thanks much!
Pingback: Pre-filling fields on EditForm.aspx » Andy Burns’ SharePoint Blog