1. We're not calling an Update. Thanks for the SystemUpdate tip, it will come in helpful elsewhere. We are merely changing beforeProperties and AfterProperties, which shouldn't (and in general) doesn't require an update since you're not touching the actual list item.
2. The thread ID is identical for both updates, as is the user id on the properties object. We're already debugging that too :) 3. No timers, no other active workflows We've done some research, and apparently this is a "not so known" issue with MOSS. It's database (not physical system) dependant, and thus far once starts happening CANNOT be fixed. I'll try to find the links our developer found last night to forward on, but it looks like we may be incredibly screwed. We're attempting to test it on another sharepoint instance on the same farm, but are guessing the issue will not happen there. Likely time for an MS support call... Here's 1 link to someone else having a similar problem: http://www.eggheadcafe.com/software/aspnet/30576548/list-event-handler-firing.aspx Note that in our case no actions are being done by system user, they're all done by the currently logged in user. On 11/29/07, Mick Badran <[EMAIL PROTECTED]> wrote: > > 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 > Blog: 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 ------------------------------------------------------------------- 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
