SharePoint Exception Occurred 0x80020009 (DISP_E_EXCEPTION)

My, oh my, will wonders never cease?

Have I mentioned how much I love SharePoint recently? Let me count the ways. And believe me, there are not 0x80020009 ways. In fact, I can count the ways on one hand. Sometimes no hands! :-)

For some reason, one of my SharePoint lists will not display in the customized Datasheet view that I created. The others custom Datasheet views on my other lists are working perfectly.

So I “Googled with Bing” for a solution and found that, lo and behold, I am not alone in the universe. Many, many more people share my woes with this error.

Some people mention that all that needs to happen is an IIS reset. Well that won’t work for me, since I’m at a very large corporation and I don’t know who the admins are nor do I even know where they are.

Some people mentioned problems with their custom web parts. No, no web parts here. The SharePoint site I’m working on does not allow custom code to be deployed to it. All I have to work with is SharePoint Designer.

Other people mentioned that it was the load balancer which was not configured properly.

Are you kidding me? One error has so many different causes? Do you think someone on the SharePoint team would think to provide us, the lowly end-users, with more of an explanation of where to look for the problem? (Before you mention reading log files or anything similar, keep in mind what I mentioned above: I don’t have access to the servers. I don’t even know where they are!)

Nice. Even though I initially found comfort in knowing that other people have encountered this error and have, in fact, found solutions, it seems that I may be all alone in this particular case.

I tried re-creating the view, just in case something mucked it up. You know, like those stray gamma rays that knock various electrons out of their paths inside your PC’s CPU which cause programs to run amuck. As you probably guessed, it didn’t work.

In fact, as of this writing, I still do not have a solution for this problem. I apologize if you have read this far expecting a solution. Or perhaps my prose caused you to skip ahead, which is good for you. The prose was good for me—it allowed me to vent some steam.

[I ended up deleting all items from the list, and the view started working. Or at least I no longer get the exception. Of course, there were no items in the list for it to display! Once I loaded it with data again, I started getting the same error. Other similar views don't give me this error. Perhaps it's a data issue.]

SharePoint? No, SwearPoint!

[Cross posted from my personal blog. -sj]

del.icio.us Tags: sharepoint,development,rant

I’ve been working on a SharePoint project for work for the past few months, and I’m getting close to the “go-live” date.  Actually, it’ll go live whenever I’m “done” (whenever that will be…).

But that’s beside the point.

The point is that I’m becoming less and less impressed with SharePoint as a development platform.  And I didn’t start out with a great love for it in the first place.

Perhaps it’s because I’m constrained to only using SharePoint Designer.  No .NET code allowed on the site I’m working on.  That bums me out right there, since I consider myself a great .NET developer.

Most of my work has revolved around customizing SharePoint lists, and using SharePoint Designer to create custom workflows to support the operations of the team I’m developing this for.  Not necessarily hard, but the requirements have been challenging to implement, to put it nicely.

One main requirement, as it turns out, isn’t really possible to implement fully in SharePoint, at least in a nice way.  There are two groups of people who are responsible for different items (a.k.a. “fields” or “columns”) in a list.  One group, let’s call them “Group A”,  doesn’t want the other group (“Group B”) to be able to modify Group A’s fields.

Now let me stop right there!  I understand that SharePoint is a “collaboration” tool, so preventing users from collaborating just doesn’t jibe with the core of SharePoint.  That’s pretty much the crux of the problem.

If it were possible to set permissions on the field level, this blog entry would not be needed.  But it is not possible to restrict access to only certain fields in a list to a certain group of people, so I had to think of ways to enable this functionality, and the way I came up with is sub-par at best.

I ended up creating 3 lists: one for Group A, one for Group B, and one which shadows Group B’s list.  Then there are workflows which copy Group A’s fields in Group A’s list to Group B’s list, and Group B’s fields in Group B’s list to Group A’s list.  The “shadow copy” list is there to prevent the workflows from running in an infinite loop—the items are only copied back to Group A’s list if they are different between Group B’s list and the shadow copy list.

As it turns out, this is not without problems, since if someone in Group A modifies one of Group B’s fields in Group A’s list (did you follow that?) then it will remain out of sync with Group B’s list, since Group B’s fields aren’t copied from Group A’s list to Group B’s list.

As it turned out, thankfully, this wasn’t as big of an issue for this particular solution (whew!).

It was my intent to set permissions on the lists such that people in Group A only had read access to Group B’s list, and vice versa.  However, as it turns out, the workflows will fail to copy data since they run as the user who initiates the change to the list.  So when a Group A person changes an item in Group A’s list, the workflow tries to copy that change to Group B’s list but can’t because Group A only has read-only access to Group B’s list.

So I thought I could change the permission to allow Group A to edit Group B’s list, but then just set the “Hide from browsers” property on Group B’s list so that Group A couldn’t find it when browsing the site.  So instead of preventing a modification of Group B’s list through the use of SharePoint Permissions, I would be preventing the modification of Group B’s list by making it very hard to find the list.  Problem solved!

Not.

Once again SwearPoint, er, SharePoint worked against me, and here’s how:

If you set the “Hide from browsers” property on the list, it does, in fact, hide the list from site when you click on the “Lists” or “All Site Content” links in SharePoint.  HOWEVER, it also hides the list from workflows!

[UPDATE: The list’s name is the only thing hidden from the workflow.  The error I was seeing which led me to the previous conclusion was due to a user-error (and, no, I wasn’t the user!).  The workflow continues to operate successfully if the referenced list is hidden.]

So my final solution still has three lists, one for each group and a third to ensure that the workflows eventually stop, and each group can see the other group’s lists.  Not at all what I set out to accomplish!

It’ll just have to be a training issue to keep each group out of the other’s list.

So much for collaboration (at least in this project).