Today we had an interesting discussion about SystemUpdate. The issue was that the metadata of a file should be updated automatically under special circumstances. I normally think about anything unusual in these cases and asked, what will happen, when a file is checked out by a user. The answer was, we will use SPListItem.SystemUpdate() that directly modifies the content in the database. I am a little bit wary in these cases and made a little test with a simple console application. This application gets a file (SPWeb.GetFile()), gets the item of this file (SPFile.Item) and does a simple modification in the title field. This simple piece of code was completed by the call of SystemUpdate() of the item.
To do the test, I logged in with another user and checked out the file our test should run with. Then I started the console application (not with the user, who has checked out the file J), and the code was executed without any error. That was not what I expected. I thought we will get an exception. But ok, having a look in the properties of our file I could see that the title field was modified, when I accessed the properties with the user, who ran the console application. The user, who has checked out the file, didn’t see this modification. From his point of view, the content of the title field was the same as when the file was checked out. I then checked in the file and…
… the modification in the title field was gone. Using SPListItem.SystemUpdate() will not do the trick, when you try to modify the metadata of a checked out file.
I did my test with SharePoint 2013, but I believe, older versions will behave identically.
