# Sunday, August 02, 2009
I hate SharePoint sometimes. It's powerful, and strong, and free(ish) and does an amazing job. If you just want to install it and use it, there's really nothing to complain about. But it's greatest strength, and my greatest user-upper of swearwords, is that you can program against it. With each release, whatever I swore about last time is magically fixed (RunWithElevatedPrivileges FTW) but a whole pile of new misery sneaks in out of nowhere. (Well, and CAML remains, but I guess we can't do anything about that.) It's usually related to security, but not always, and the thing is that debugging it is always like surgery with oven mitts on.

I had a situation where I wanted to find the item you just added. Took a little searching, but I found it:

query.Query = "<Where><Eq><FieldRef Name='" & list.Fields.Item("Created By").InternalName & _
                "'/><Value Type='User'>" & SPContext.Current.Web.CurrentUser.Name & "</Value></Eq></Where>" & _
            "<OrderBy><FieldRef Name='Created' Ascending='FALSE' /></OrderBy>"
items = list.GetItems(query)
The first entry in items is the thing you most recently added. OK, fine. But we have event receivers on these lists, and they go off asynchronously. That means that right after you saved an item, while the receiver is still processing, the item isn't returned by the query.

Well that made me grumpy but I understood, so I made a loop, and if the first entry in items wasn't recent enough (say, in the last two minutes) I would have a little sleep and then ask again. But no matter how long I waited (even 20 minutes!) this code never would find the item. Oh, there was swearing, you can be sure of that.

I decided that SharePoint must be caching the query results. But searching for things like "SPListItemCollection cache" just got me helpful tips on caching these results myself, some thread safety issues, and the like. For example, this MSDN article says

You might try to increase performance and memory usage by caching SPListItemCollection objects that are returned from queries. In general, this is a good practice; however, the SPListItemCollection object contains an embedded SPWeb object that is not thread safe and should not be cached.

Does that match up well with what I am seeing - always the identical results from this query-in-a-loop even though I know the underlying list has changed while the loop was running? It does not.

Then I found two blog entries by Jeff Crossett: first the complaint, and then the solution. He's right. And when I implemented his hack:

' use a random value in query so we don't get cached.
randomValue = generator.Next(100, 1000000000)
query.Query = "<Where><And><Eq><FieldRef Name='" & list.Fields.Item("Created By").InternalName & _
                "'/><Value Type='User'>" & SPContext.Current.Web.CurrentUser.Name & "</Value></Eq><Neq>" & _
                "<FieldRef Name='Title' /><Value Type='Text'>" & randomValue.ToString & "</Value>" & _
                "</Neq></And></Where>" & _
            "<OrderBy><FieldRef Name='Created' Ascending='FALSE' /></OrderBy>"
items = list.GetItems(query)

We all lived happily ever after. Well, until the next WTF that SharePoint throws my way. I am doing amazing things with this product. My customers would pay more for their software if SharePoint didn't exist. But man, sometimes it is HARD.

Kate

Sunday, August 02, 2009 8:26:35 AM (Eastern Daylight Time, UTC-04:00)  #