I've got an Event Receiver for when a list item is Updated (ItemUpdated and not ItemUpdating). Inside the receiver I then update the list item again. This naturally sets off some recursive event calls as I would expect. Putting a break point at the start of the event handler, I count it stoppping in the event 10 times and then it just finishes. Might there be some sort of recursion protection inside SharePoint exactly to protect against this sort of thing?
+7
A:
Use the DisableEventFiring Method
base.DisableEventFiring();
item.update();
base.EnableEventFiring();
F.Aquino
2009-12-03 20:05:41
This is the ONLY *correct* way of doing this in SharePoint 2007, and EventFiringEnabled = true/false; is the ONLY *correct* way of doing this in SharePoint 2010.
mjsabby
2010-01-25 03:54:02
+2
A:
Or use item.SystemUpdate(), SystemUpdate does the update without triggering any event attached to the item.
Colin
2009-12-03 22:17:00
I use both of these together. I have had cases where SystemUpdate has not stopped the recursion without also having DisableEventFiring. And even we I use DisableEventFiring, I also call SystemUpdate(false) because I do not want to change the Modify By or Item Version from within the Event Receiver.
Rich Bennema
2009-12-08 15:24:56
-1.This is NOT accurate, SystemUpdate() is an opaque method whose implementation you do not know, it's only documented to update without affecting changes in the Modified Time or Modified By fields, or optionally, the item version.It's used internally by SharePoint for things like Discussion Boards, where you don't want to modify the original author of the post, etc.Events do fire, in fact the functionality you are relying on right now for stopping event propogation was almost about to be changed in SharePoint 2010, and may in the future.
mjsabby
2010-01-25 03:42:51
http://blogs.msdn.com/mjsabby/archive/2010/01/24/disabling-events-in-sharepoint-2007-and-sharepoint-2010.aspx
mjsabby
2010-01-25 05:23:25