Avoid the SPListItem.Properties HashTable

Posted Tuesday, February 2, 2010 2:55 PM by CoreyRoth

One thing is a lot of confusing to new SharePoint developers is that there are so many ways to use the API to get to the same data.  When it comes to getting or setting the value of a field on a list item, there is at least 2 ways I can think of immediately (we all know there is more).  One way to do this is use SPListItem.Properties.  This is a Hashtable that allow you to get and set values as you please.  If all of your properties are strings, you are pretty safe to use this, however where you might start running into issues is when you start dealing with other types.  If I remember correctly from an error I received once, when assigning to this, you can only use a string, int32, or DateTime.  The problem is you never know what underlying type is going to be there when you try to assign it. 

I ran into this problem again recently in an event receiver which was copying data from one list item to another.  The code was for some simple metadata inheritance if you were curious.  We had no issue copying strings.  However, the source item thought property MyField was a string and the destination item thought property MyField was an int32.  Here is what it looked like.

destionationItem.Properties["MyField"] = sourceItem.Properties["MyField"];

Now you might be thinking that you can just cast it or that I have some other issue because they should be the same type.  This really wasn’t the case though.  In my case, I had stored a value of 2, but when I retrieved the value I received back “2.0000000000”.  This makes things quite a pain, since int.Parse can not handle that.  All of this was just simply not worth the hassle.

The one thing you need to remember is that using the indexer on SPListItem is not the same as using SPListeItem.Properties.  To repeat.

SPListItem[“MyField”] != SpListItem.Properties[“MyField”]

Both will return a type of object by default, but when you retrieve the value using the indexer you actually get the type of double (in my case above).  Better yet, the type matches on both the source and the destination field.  I then can simplify my code to copy the properties as shown below.

destinationItem["MyField"] = sourceItem["MyField"];

Now I am no expert on the SharePoint API by any means.  I’m sure there might be a reason you might prefer using the Hashtable (maybe it performs better), but for now I am going to stay away from it.  At the minimum, I’ll avoid it when I am copying data.

Filed under:


# re: Avoid the SPListItem.Properties HashTable

Wednesday, October 20, 2010 1:32 PM by Christian

Do not worry, I have encountered this issue before.

Unfortunately you will find that sometimes Properties is more reliable than using the default accesor. Why? The default accesor sometimes simply fails.

It is still a pain in the ass for me, because you can not query if your operation will perform well or not, so you might have to do some try catches sometimes.

And dont get me started while copying data from an Item in another List.

Leave a Comment