ItemUpdated event firing multiple times when using explorer view
Bloqueada
-
Tuesday, January 26, 2010 3:45 PM
I have an ItemUpdated event receiver attached to a custom document library. If I upload files by using the upload button, the event fires once as expected. If I use the explorer view or the button "open in explorer" in the actions menu, the event is often fired twice or even three times. Does anybody know why this is happening? I guess that it is maybe fired when the upload starts and after the file is fully uploaded it is fired again, but I'm not sure. I want to avoid that the code in the receiver is executed multiple times, so I'd appreciate your help on this problem!
I already know that the check-in also leads to an ItemUpdated event, but I already check this in my receiver.
During debugging I also sometimes get a "Windows - Delayed Write Failed" message if this is useful information for anybody.
All Replies
-
Thursday, January 28, 2010 4:47 AM
Hi,
Would please first confirm that you have used DisableEventFiring() EnableEventFiring() method to avoid event firing multiple times?
Besides, please also let me know your client Operating System. For Vista client, it may has this special behavior.
To avoid multiple firing, besides DisableEventFiring() EnableEventFiring() , we have another option:
Creating a static Boolean variable and updated its value whenever there is an ItemUpdated event,
and whenever there is a second ItemUpdated event fire due to the loop then we set the value to false and exits from the event.
See this solution in this post:
Hope this can help.
Best Regards,
-Aaron
-
Thursday, January 28, 2010 4:48 PMHi Aaron,
the event is fired even before I call any update-methods. And I am also using DisableEventFiring().
I am currently testing on Windows Server 2003 - do you think that this could be the reason? If it also happens in Vista I a least have to assume that users may have Vista installed.
Concerning the static variable: I thought that this variable would then be shared across all event handlers - even the ones for different items that are possibly uploaded from other users at the same moment. So it could happen that an item of a different user is not updated due to a thread switch. Or am I wrong?
Thanks for your help!
Mel -
Thursday, January 28, 2010 5:33 PMThe "Windows - Delayed Write Failed" means that while you are debugging all processes have stopped for the SharePoint side, but it is still waiting for an upload event to have and it never does so it times out.
-
Friday, January 29, 2010 8:55 AMThanks for this hint, but I now noticed that the "Delayed Write Failed" message is also occuring when I am not debugging. In special cases I am cancelling the ItemUpdating event and it seems that the error occures also in this case (and the error message I specified in the properties of the event is not displayed as well).
-
Friday, January 29, 2010 9:08 PM
I think that the event fires multiple times due to the following errors in the event log:
PROPPATCH failed for file xy on SetFileInfo. ErrorStatus: 31. (twice)
PUT failed for file xy on Close. ErrorStatus: 87.
Then the "delayed write failed" arises and this seems to stop the event firing. The file is uploaded although I cancel the event. I a different forum I found a hint that these error messages occured on machines that were not part of a domain which is also true in my case. I will test if changing this solves the problem. -
Tuesday, February 02, 2010 11:51 PMOk, so now I tested on a machine that's part of a domain and the "delayed write failed" error did not occur any more. So far so good!
But still, the error message that I want to show when cancelling the updating event is not shown. Instead, a generic error message is shown. Has anybody managed to display a custom error message when using the explorer view?
And I noticed another strange thing: in the msdn I read that when adding a file in explorer view, both ItemAdding and ItemUpdating events are fired. This was also true on the machine not in the domain. On the new test machine, the ItemUpdating event is not fired any more. I would of course prefer this behaviour, but I'm not sure if I can rely on this. Does anybody know if this could be a change in the latest service pack or update package?
Thanx for your help. I'm starting to get really frustrated ... -
Friday, February 03, 2012 8:43 AM
I have used the following solution
if (properties.Versionless) { base.ItemUpdated(properties); }
Explorer view
The first event trigger Versionless will be false and in the second one will be true.
Normal Upload
The first event trigger Versionless will be true.
This helps the event handler code to behave the same way for both scenarios.
Hope this helps.
Moderator Note: NEVER Propose your own posts as answers(This is in any case a thread from two years ago. Spend your time on recent threads - don't hunt for old threads you can reply to as the posters and their problems are long gone.)
- Proposed As Answer by Balaji Kandasamy Friday, February 03, 2012 8:44 AM
- Unproposed As Answer by Mike Walsh FIN Friday, February 03, 2012 8:45 AM
- Edited by Mike Walsh FIN Friday, February 03, 2012 8:47 AM Moderator note added about never proposing own posts as answers added
- Edited by Mike Walsh FIN Friday, February 03, 2012 8:48 AM (This is in any case ... ) added
- Marked As Answer by Mike Walsh FIN Monday, February 13, 2012 1:19 PM
-
Monday, February 13, 2012 10:58 AM
Hi Balaji,
Currently we are facing the same issue. Thanks for your useful information, it helped us.
Viji

