Cannot update document property on ItemAdded event when using Vista

Question

We are trying to create a custom event handler that would fire on ItemAdded event. The event handler then updates the document with a unique ID value to a column in this document library.

Our solution works fine, except when a user on Vista is trying to save a new document from Office 2007. In this scenario the document is stored to document library but Unique ID column is empty, and there is no exception.

Vista Users can upload document(s) to library without a problem. Everything else works fine on XP and Win2k3 operating systems.

Has anyone seen something similar, and what might be the problem here? To demonstrate the problem we are using DateTime.Now as unique ID.

 using Microsoft.SharePoint;

 public class TestReciever : SPItemEventReceiver
 {

     public override void ItemAdded(Microsoft.SharePoint.SPItemEventProperties properties)
     {

         try {
             DisableEventFiring();

             properties.ListItem("UniqueID Column") = DateTime.Now.ToString();
             properties.ListItem.SystemUpdate();

             EnableEventFiring();
         }
         catch (Exception ex) {
             // handle exception
         }


     }
 }

Thanks, Toni

Answer 1

We have noticed exactly the same thing happening. When the 2007 doc is added to the library, the properties from the list are added to it (blank).

Then the (synchronous) event handler is called, updating the list with the correct values for the UniqueID column.

Then the inbuilt property mapping to 2007 docs kicks in and overwrites your values with those stored in the 2007 doc (not raising an item updated event again).

This means that the list now has a blank for your column.

If you change to an asynchronous event you may see what we did and that the slight delay for asynchronous meant that the property mapping to 2007 docs happened first (we think) meaning the value was stored correctly.

It is possible to break the property mapping between the list and office, but that is only a workaround.

I cannot for the life of me find where this info is on an MS site, but it is a known problem. Perhaps you can hang in there for SP2 (may even be fixed in SP1, but am unsure).

Answer 2

At the end we contacted Microsoft and they provided us with the following workaround solution. The key here is to delay item update in a separate thread.

private Guid listID;
private Guid itemID;
private Guid siteID;



public override void ItemAdded(Microsoft.SharePoint.SPItemEventProperties properties)
{
    DisableEventFiring();

    item = properties.ListItem;
    listID = properties.ListId;
    itemID = properties.ListItem.UniqueId;
    siteID = properties.SiteId;

    Threading.Thread setDocumentInternalIDThread = new Threading.Thread(SetInternalID);
    setDocumentInternalIDThread.Start();


    EnableEventFiring();
}


private void SetInternalID()
{
    try {

        Threading.Thread.Sleep(10000);
        using (SPSite site = new SPSite(siteID)) {
            using (SPWeb web = site.OpenWeb()) {

                SPList list = web.Lists(listID);
                SPListItem item = list.Items(itemID);

                item(Common.CustomID) = Common.GetAlphaPrefix() + Common.GetDocNumber();
                item.SystemUpdate();
            }

        }
    }
    catch (Exception ex) {

        Log(ex.Message);
    }
}

Answer 3

Why doesn't exist something better that this poor solution!!!???

Answer 4

Another workaround is to set the custom field that is being updated in the event receiver to be read only (set the fields ReadOnly property to TRUE). This has a few pros and cons. This is ideal for a unique id solution, because there is no way for the user to modify the value. However, the field is hidden to the UI, so managing it becomes more troublesome, and the field can't be used in labels, or quick parts. You can set the ShowInDisplayForm property of the field to TRUE to have the field display in the view form, but not the edit form. The field can also be added to your views. This is the best workaround I have found for this issue to date.

This is an issue with Office 2007 and the WSS 3.0 xml parser. When the properties are promoted from the Office 2007 document, the parser attempts to assign document properties to the list properties in SharePoint (property promotion). The problem is that this event occurs after any ItemAdded, or ItemUpdated events, so the property gets overwritten with the value in the document, which is of course, blank. Microsoft has raised this as a bug, and I was hoping for a fix in SP2, but no such luck.