Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have an event receiver that creates/updates/deletes publishing pages in a publishing library.

In ItemUpdating, I get a handle to the page's underlying ListItem, change some of its properties and then update it. Finally I update the page, publish, and approve it.

var listItem = defaultPage.GetListItem();
defaultPage.CheckOut();
listItem[someField] = someValue; 
listItem.Update();
defaultPage.Update();

defaultPage.CheckIn("Checked in on update.");
defaultPage.Publish("Published on update.");
defaultPage.Approve("Approved on update.");

This all works great when the page status is Published - I determine that by checking the value of listItem.File.Level.

There are three other scenarios that I need to work with:

1. The page is checked out, but not changed or saved back.

If the user checked out the page but didn't make any changes, I can call defaultPage.UndoCheckOut(); and continue on. In this case, Level is SPFileLevel.Checkout.

2. The user checked out the page, made some changes, saved them, but didn't check the page back in

If the user checked out the page, made some changes and saved them, Level is still SPFileLevel.Checkout, but the call to listItem.Update(); fails with the following exception.

The file Pages/default.aspx has been modified by DOMAIN\User

3. The user checked the page back in after making changes. Here, Level is SPFileLevel.Draft, I can simply check out the file and do what I need to do.

Any thoughts on getting around the issue in #2?

share|improve this question
    
Can't you just force CheckIn and then proceed as normal with the Update? –  Kit Menke Jun 22 '11 at 21:37
    
Kit, had a typo in the last sentence (fixed). The one that I need help with is when another user has checked in changes. Thanks. –  George Durzi Jun 22 '11 at 22:31
1  
I don't see any issue with #3? First, you'll have to validate if it is checked out by another user.. yes? then force check in. Then, proceed with your check out and update. –  Kit Menke Jun 23 '11 at 1:04
    
Kit, I tried that and saw that the error happens even when I check the other user's changes in. –  George Durzi Jun 27 '11 at 13:15

2 Answers 2

up vote 1 down vote accepted

It may be that after you check-in the other user's changes, you need to get an updated instance of the SPListItem, and then call listItem.Update() on that instance. I've seen this error before when SharePoint detects that the item you are trying to commit to the database is an older version than the one that is currently committed.

share|improve this answer
    
Jason, is this the right sequence? Check in the other user's changes, get an updated listitem, make my changes, update? –  George Durzi Jun 30 '11 at 19:49
    
Yes, that sounds about right. Did you get a chance to try this? –  jason.venema Aug 3 '11 at 21:07

I have this solution for the #2:

Before "listItem.Update()" insert "properties.InvalidateListItem()"

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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