1

The reason why item-updating event receiver fires twice in case of document libraries is because of check-in/checkout.

Also it can fire twice in case of doc library/list if we are updating the current item values with in this item updating event.

How can we handle both these cases via code?

2 Answers 2

4

For the scenario when you are the one triggering the second ItemUpdating by changing item values you can use the EventFiringEnabled parameter (you should use a try - catch -finally around it):

this.EventFiringEnabled = false;
// Do the changes
item.Update();
this.EventFiringEnabled = true;

The other scenario is tougher, and the reason behind why I use ItemUpdated instead when ever possible!

You could check the BeforeProperties, ListItem and AfterPropertiesin your ItemUpdating event receiver to check if there is updates being made that you have to take action on. If not, then just return.

Here is a guide for when you can use .BeforePropertiesand when you should go in the .ListItem instead

4
  • Is this also applicable to item-updated events?
    – variable
    Aug 6, 2014 at 7:50
  • You really should not add more questions to a question after receiver answers (it could mean the existing answers looks strange if oyu know what I mean). But yes, you can use the EventFiringEnabled in ItemUpdated to, but you can not use AfterProperties (since the item is already updated when this event i triggered) Aug 6, 2014 at 7:52
  • Robert, what did you mean in your answer by "The other scenario is tougher", which scenario?
    – variable
    Aug 6, 2014 at 7:59
  • The one you talk about first (check-in / check-out), it's quite clear in my post I think Aug 6, 2014 at 8:00
5
public override void ItemUpdating(SPItemEventProperties properties)
{
  try
  {
    //is the item checked out?
    if (isCheckin(properties) == false)
    {
         this.EventFiringEnabled = false;

         //do your stuff

    }
  }
  catch(Exception a)
  {
    //catch any errors
  }
  finally
  {
    this.EventFiringEnabled = true; 
  }
} 

private bool isCheckin(SPItemEventProperties properties)
{
    if (properties.AfterProperties["vti_sourcecontrolcheckedoutby"] == null 
         && properties.BeforeProperties["vti_sourcecontrolcheckedoutby"] != null)
    {
        return true;
    }
    return false;
}

https://www.simple-talk.com/dotnet/.net-tools/managing-itemupdating-and-itemupdated-events-firing-twice-in-a-sharepoint-item-event-receiver/

@Robert about the before properties, yes your right they would be the same regardless.... only possible solution that i can think of would be using this instead

private bool isCheckin(SPItemEventProperties properties)
{
    string BeforeVal = properties.ListItem["vti_sourcecontrolcheckedoutby"];

    if (properties.AfterProperties["vti_sourcecontrolcheckedoutby"] == null 
         && BeforeVal != null)
    {
        return true;
    }
    return false;
}
5
  • The isCheckin method is pretty sweet! Never seen that one before Aug 6, 2014 at 7:14
  • yup encountered it a few years back when i had similar issue!, the key is checking both properties of the checked state field and from that we know if its checked in or out
    – Ali Jafer
    Aug 6, 2014 at 7:16
  • The only problem I can see with it is for Lists (not libraries) where BeforeProperties is always empty Aug 6, 2014 at 7:17
  • Clever, but shouldn't EventFiringEnabled be scoped in using or try catch finally, to make sure its turned back to its original state if an error occurs Aug 6, 2014 at 7:26
  • 1
    Here is some cool examples for how to create a scope of it @AndersAune adrianhenke.wordpress.com/2010/01/29/… Aug 6, 2014 at 7:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.