Do you have a .Update() somewhere on the item? If you do replace with a .SystemUpdate() - causes no events to fire :-)
It may also be worth getting the ThreadID that is doing the updates?? Given that this is a publishing site - are there any 'default/system' workflows on this causing changes to occur in the background? Timer jobs etc.? It would be worth getting the module owner of the ThreadID (usually w3wp.exe or OWSTimer.exe) Can you try the same logic outside of a publishing site? Mick Badran (MVP - BizTalk) | mb: +61 404842833 | im:[EMAIL PROTECTED] Breeze Training | Training + Integration Specialist | Microsoft Readiness Instructor blogs:http://blogs.breezetraining.com.au/mickb ________________________________ From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Ishai Sagi [EMAIL PROTECTED] Sent: Thursday, 29 November 2007 9:38 AM To: [EMAIL PROTECTED]; [email protected] Subject: [OzMOSS] RE: [derelict-techies] Event Receivers firing multiple times note - writing from memory, so I may be off on a few points here... To begin with, since you are not updating in the code, you dont really have to disable events. Changing the AfterProperties does not (should not) trigger another event anyway. Now, I am assuming where your wrote "testTest" you meant "testText". My assumption (that I will have to verify) is that when you check in, there are several events - the save, and the check-in - both triggering an item update event. You can see in the object model that the two are seperate - if you want to update a file from OM you got to first call the ".Update" and then the ".Checkin" Ishai Sagi Solution Architect Information Management MVP Microsoft Office SharePoint Server Direct: 02 8001 7717 Fax: 02 8001 7778 Mobile: 0423 791 728 Email: [EMAIL PROTECTED] Web: www.uniqueworld.net<http://www.uniqueworld.net/> Blog: www.sharepoint-tips.com<http://www.sharepoint-tips.com/> innovative business solutions that make a difference ________________________________________ From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Bill Williamson [EMAIL PROTECTED] Sent: Thursday, 29 November 2007 9:32 AM To: [email protected] Subject: [derelict-techies] Event Receivers firing multiple times ANY ideas on the below problem? It's lengthy, but really weird. Short version is that event receivers on publishing libraries attached to ItemUpdating fire twice with random results... We have a content type with: -an integer column called "testCount" which defaults to 0 -an html content field called "testText" We have an event handler attached to itemupdating. It does the following: (pseudocode shortcuts used, we're getting proper field names/etc, and there is try/catch around appropriate places) ---------------------CODE------------------------- DisableEvents(); int counter = Convert.ToInt32(properties.BeforeProperties["testCount"]); counter++; properties.AfterProperties["testCount"] = counter; Debug("Before:" + properties.BeforeProperties["testText"])); Debug("Item:" + properties.ListItem["testText"])); Debug("After:" + properties.AfterProperties["testText"])); properties.AfterProperties["listText"] = "Edited AfterProperties: " + DateTime.Now; properties.status = Statuses.Continue EnableEvents(); ---------------------END CODE------------------------- Note: this is attached to a publishing area with "/Pages" and all the publishing stuff active. That may or may not be relevant. Test cases: -Open a page with count at 0 -Click edit -Change testTest to "Bill Test A" (then B, then C, etc in subsequent tests) -Click "check in" Results: -testCount goes to 2 -listText SOMETIMES is Bill Test A, sometimes is our datetime set -our debugging log shows that the handler runs twice Now, repeat the test with Bill Test B -testCount goes to 4 -the Before/Item/After debugs happen twice (showing two list runs). Now for the funny bit: --it debugs once the OLD date time --it debugs once "Bill Test B" -testText DOES wind up as our new dateTime.Now most of the times Now, repeat the test 5 more times WITHOUT EDITING listText results: -testCount sometimes goes up 2, sometimes doesn't go up at all (only the first two tests always raise testCount) -Before/Item/After debugs twice each time: --debugs once "Bill Test B" (a value which hasn't been around for 4 edits by the end!!! remember I'm NOT editing that column) --debugs once the OLD dateTime string (as you'd expect) -testText DOES wind up as our new dateTime.Now most of the times Whiskey Tango Foxtrot, over. --~--~---------~--~----~------------~-------~--~----~ CUSTOM FOOTER HERE BECAUSE THE TECHIES HATE WHITE SPACE -~----------~----~----~----~------~----~------~--~--- ------------------------------------------------------------------- OzMOSS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net ------------------------------------------------------------------- OzMOSS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
