so I use quite a bit of the javascript client object model for CRUD operations to lists from custom pages (inputs) and I have found that I get version conflict errors on saves from time to time....its very intermittent which has made it more confusing to me.

I can't seem to find anything on this error, except discussions in other boards, etc and the few things I have seen there I have tried but I still get these.

One suggestion was getById(#) gets cached, so instead of getting list items that way, use CAML for the id filtering....no big deal; easy to fix that then but it doesn't seem to help. I believe that my updates are what is throwing this error, but then again I don't even know the basic principle with why. If I have a loop for each item that meets criterion I want to call an update for that item which means there may be several:

for ( var I = 0 ; I < myDataObj; I++ ) {
   var thisData = myDataObj[I];
   if (thisData.thisVal == thisOtherVal) {
       updateThisItem(thisData.thisItemId, thisData.thisVal);

function updateThisItem(thisId, thisUpdateVal) {
var clientContext = new SP.ClientContext(siteUrl);
    var oList = clientContext.get_web().get_lists().getByTitle('myListName');
    this.oListItem = oList.getItemById(thisId);
    oListItem.set_item(Custom, thisUpdateVal);
    clientContext.executeQueryAsync(Function.createDelegate(this, this.onUpdatedItemSuccess), Function.createDelegate(this, this.onUpdatedItemFailed));


function onUpdatedItemSuccess() {
    alert('item updated');

function onUpdatedItemFailed(sender, args) {
    // sometimes I get error: version conflict

when I do get that error though, the item from what I can see has still been updated?

1 Answer 1


If you are updating a list item more than once in succession, after the first update the list item (oListItem in your case) object will have become stale, and the server will reject the update.

SharePoint uses a hidden field called owshiddenversion, which gets downloaded along with your CSOM object, to determine which version you are editing. When you send your update, the server checks that owshiddenversion to determine if the data is stale. If that field is not what it expects, the server will reject the update and send that version conflict message.

To get around this you need to request a new version for every update you make. Simply run: this.oListItem = oList.getItemById(thisId); and call execute query again and oListItem will be "fresh" again.

Stefan Stanev has (in a web services context, but the idea is the same)a great blog post which goes into more detail on this hidden field:

"And if you intend to do several updates in a row on a certain list item you should either re-fetch the item after each update to have the updated value of the owshiddenversion field for the next update (this is what actually happens when you update an item with SPListItem.Update) or be more economical and increment the value by one yourself. "

  • I appreciate the answer and help. I am just a bit confused as to how I would apply the suggest line/concept above? should i use the same line (this.oListItem...) in the failed callback..thats not right, right? where is the actual refresh taking place in javascript? greatly appreciate the help!
    – Justin
    Jul 23, 2013 at 13:17
  • 2
    Think of it this way...suppose you fetch the list item (say version 1), and post an update. The server now has version 2. Now you make another update. The server sees a user is trying to update version 1, which it sees as out of date, so it rejects it. The solution is, immediately after you make the update, call getItemById() again to fetch the latest version. The asyncronous nature of the CSOM complicates this somewhat, you'll have to figure out the best way to handle the callbacks based on your exact flow. Jul 23, 2013 at 14:03
  • yeah so I am doing this I believe but I use REST/JSON for all the GETs. I wonder if this hiddenversion is lost in the mix. which i didn't mention: question fail, but i really appreciate help with the context.
    – Justin
    Jul 23, 2013 at 18:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.