locked
item.Update() fails, hard RRS feed

Answers

  • I tried the file.CheckOut()/file.CheckIn() workaround, but that just made the problem worse. I also am not able to change to the ItemAdding() event for various reasons, though that tidbit may be useful in the future.

    What I've done is the most awful thing: just wait a few minutes and hope the whole thing blows over. I'll note that in order to use a multi-minute delay, I had to switch back over to a Workflow, abandoning my hook into ItemAdded(). If you're thinking of doing a "Thread.Sleep(5 minutes);" inside your ItemAdded() event, don't. Those threads will remain open/blocked and will kill your production environment. I tried it, it bombed after attempting to upload the 23rd item (hint: 25 threads per process Smile ).

    Thankfully Workflow takes care of dehydrating/rehydrating threads for us...this is why you have to use Workflow.

    Anyway, this is resolved, at least for me. I'm still running the tests, but it looks like we're going to have 0 failures out of 1000.

    For those who may come across this in the future, let me say a few things:
    • Don't trust ItemAdded() at all, or any code you call from ItemAdded(). If you think everything's working, try and set up an automated test that runs 1000 times, and see how many of those times your process fails. I'm assuming that many of the links I link to above, in many of their cases, didn't test their code with the same scrutiny.
    • Don't trust others' posted solutions. In the same vein as above, verify yourself whether this works, not whether some guy on the internet posted a code workaround.
    • Instead of ItemAdded(), use a Workflow with at least a 5 minute delay at the beginning.  I chose  "5 minutes" arbitrarily, feel free to choose your own delay.
    • Don't trust your Workflows that update an item immediately after it's been added. You may not know this, but if you check your list.EventReceivers, Workflow hooks into ItemAdded() just like your custom code does. And your code may have worked for you on your VM, once, but did it work 1000 times out of 1000? Now I'm curious to see what vendors like Nintex do about this situation, they must get all sorts of related support calls.
    • This affects all kinds of documents:
      • Documents (duh)
      • Pages
      • InfoPath forms in a Form Library
      • incoming emails
    Monday, June 16, 2008 8:31 PM

All replies

  • Hi,

    try to checkout your item before and checkin after your work...

     

    regards...

    Saturday, June 14, 2008 9:21 PM
  • Have you tried using the ItemUpdating event. You can set the AfterProperties and it should give you the ability to update properties right before they get committed to the list. You don't even have to call Update. The ItemUpdating event is synchronous and the ItemUpdating event is asynchronous. Thus, you sometimes see weird behaviors in asynchrounous events.

    There is some caveats to this approach:

    1. The SPListItem isn't created yet. Thus, you can't update through the item - you have to use the afterproperties hash table. Note: this might only be an issue when using ItemAdding (I am not sure if it is an issue with ItemUpdating or not).

    2. You have to use the internal name of the field.

     

    Take a look at this posting which talks about setting fields with ItemUpdating - http://www.sharepoint-tips.com/2006/09/synchronous-add-list-event-itemadding.html. I believe the author of this posting is a frequent visitor to this forum also.

    Saturday, June 14, 2008 9:30 PM
  • Thanks both for the hints. I'm going to try both methods and report back.

    I will take the time to point out: this sort of "mostly works" behavior is unacceptable, and had better not still exist in vNext. -Peter
    Monday, June 16, 2008 2:45 PM
  • I tried the file.CheckOut()/file.CheckIn() workaround, but that just made the problem worse. I also am not able to change to the ItemAdding() event for various reasons, though that tidbit may be useful in the future.

    What I've done is the most awful thing: just wait a few minutes and hope the whole thing blows over. I'll note that in order to use a multi-minute delay, I had to switch back over to a Workflow, abandoning my hook into ItemAdded(). If you're thinking of doing a "Thread.Sleep(5 minutes);" inside your ItemAdded() event, don't. Those threads will remain open/blocked and will kill your production environment. I tried it, it bombed after attempting to upload the 23rd item (hint: 25 threads per process Smile ).

    Thankfully Workflow takes care of dehydrating/rehydrating threads for us...this is why you have to use Workflow.

    Anyway, this is resolved, at least for me. I'm still running the tests, but it looks like we're going to have 0 failures out of 1000.

    For those who may come across this in the future, let me say a few things:
    • Don't trust ItemAdded() at all, or any code you call from ItemAdded(). If you think everything's working, try and set up an automated test that runs 1000 times, and see how many of those times your process fails. I'm assuming that many of the links I link to above, in many of their cases, didn't test their code with the same scrutiny.
    • Don't trust others' posted solutions. In the same vein as above, verify yourself whether this works, not whether some guy on the internet posted a code workaround.
    • Instead of ItemAdded(), use a Workflow with at least a 5 minute delay at the beginning.  I chose  "5 minutes" arbitrarily, feel free to choose your own delay.
    • Don't trust your Workflows that update an item immediately after it's been added. You may not know this, but if you check your list.EventReceivers, Workflow hooks into ItemAdded() just like your custom code does. And your code may have worked for you on your VM, once, but did it work 1000 times out of 1000? Now I'm curious to see what vendors like Nintex do about this situation, they must get all sorts of related support calls.
    • This affects all kinds of documents:
      • Documents (duh)
      • Pages
      • InfoPath forms in a Form Library
      • incoming emails
    Monday, June 16, 2008 8:31 PM
  •  

    Hi, I have the same problem of save conflict with ItemAdded events. I switched from events to workflows. But now the problem is, I want the workflow to run if an item is added or updated. In the workflow I am updating the same item. So its going into infinite loop. Is there a way I can avoid infinite loop in workflows as I cant disable firing it before I udpate the item. Or else I have to stick with events and keep a multi-minute delay which will overload the process with sleeping threads. Is there a work around for this?

     

    Thanks,

    Bhuvan.

    Monday, July 21, 2008 7:25 PM
  • In the end, as I couldn't get my workflow solution working (unrelated reason), I just switched to hourly timer jobs to do the same thing my workflow was supposed to do. It's a bad solution, but it works and I can move on.

     

    I recommend you ask your question in the workflow forum, I'm sure they'll have an actual solution for you.

    Monday, July 21, 2008 7:31 PM
  • I have  a question for PSeal, how did you setup your automated test to run 1000 times?  Did you use something like ACT or another s/w testing package, or home grown?  Sounds like a nice stress test mechanism, curious as to what/how you did it.

    KevinHou
    Friday, October 3, 2008 7:38 PM
  • Valvem,

    The answer is to eliminating the infinite loop is to upgrade to SP2.

    Source:
    http://blogs.msdn.com/sharepointdesigner/archive/2009/07/13/service-pack-2-prevents-an-on-change-workflow-from-starting-itself.aspx

    Regards,
    Greg L.
    Tuesday, August 4, 2009 7:54 PM
  • I have the same issue but I don't want to solve this with a workflow.

    I wrote a Outlook Addin Script for saving emails directly to a sharepoint library. So i get an email, move this email to a special folder and my outlook addin will save this file in this special folder directly to the library.This works great, but sometimes I got the Error, that the File .... has been modified by.... and so on

    Well I use a ItemAdded eventhandler for reading out the email header and write this informations in the sharepoint columns (subject,from,to,received and so on).

    Sometimes it works well and sometimes I got the error and the listitem won't be updated. So i decide to check, if Itemupdated will work, but if I simply upload my mail with my addin (simply saveas(Target-path) function) to sharepoint, there will no Itemupdated event fired so I can't use my code in Itemupdated.

    Anyone who can help me?

    Thanks a lot
    Wednesday, January 20, 2010 10:31 AM