For example, if you define an instance level variable in the class to store data in the Item Updating event, then try to access that data in the Item Updated event, you will find that the data is not there when you go to check it in the Item Updated event.
This is because you have two classes – one that is handling the Item Updating event and in which the instance level variable is set, and one that is handling the Item Updated event in which the instance level variable is not set.
Item Event Receivers derive from the SPItem Event Receiver class and have a number of methods that can be overridden to respond to various events: As you look through this list, you should notice that events have two types of endings: WARNING: One major gotcha you should know about the SPItem Event Receiver class is that while you can implement multiple list item event handlers in a single class, Share Point instantiates a new instance of that class for each individual event it needs to handle.
What this means is that you cannot store data in instance-level variables and share that data between event handlers.
Turning off the Require Check Out option is a great quick fix if you don’t require the item to be checked out in order for it to be edited.
But that option exists to be used, and some people really do need it.
If you find yourself in this situation, then you’ll have to solve the problem in code.
Fortunately, there is a relatively simple way to check whether the Item Updating and Item Updated events are firing in response to a check-in outlined in Knowledgebase Article 939307.
I am nothing if not a masterful linguist after a beer or two or more.
I don’t mean that it’s largest and most luxurious application every written, but rather that you may be cruising headlong into a nasty rendezvous with an iceberg that could deal a severe blow to your project.