Connected Web Parts are bugged in SharePoint 2010

Update: This is an intentional design change, see the Microsoft answer in this thread.

Just stumbled upon a bug in SharePoint 2010. Imagine this scenario: You have two lists and add them to a Site as DataForm WebParts. You then configure the Web Parts so that one of them sends Filter values to the other one and uncheck the option for "Send first row to connected Web Parts when page loads". You refresh the Page and notice that the list that receives the Filter (the Consumer) does not show any items because the list that provides the Filter (the Provider) does not have any items selected.

In SharePoint 2007, not selecting an item in the Provider List would cause the consumer List to display all items instead, which was (at least for us) highly desirable. In SharePoint 2010, you have to select an Item in the Provider to provide a filter and there is no way to have the Consumer List display all items anymore.

The reason why I think this is a bug is the result of an extended Debugging session that eventually led me to the class Microsoft.SharePoint.WebPartPages.DataFormWebPart and specifically it's method ApplyReceivedFilterData. I'm not going to paste the source of this class, but the culprit is this line: if (dictionary2[str] != null)

This is supposed to only add Filters that have a value and skip the ones that are null. The problem is that dictionary2[str] is not null but DBNull, which then causes SharePoint 2010 to process the value anyway and generate a nasty <Query><Where><IsNull><FieldRef Name="FieldToReceiveFilter" /></IsNull></Where></Query> in the SelectCommand of the underlying DataSource

Unfortunately, DataFormWebPart.ApplyReceivedFilterData is not virtual, so sub-classing it does not seem to be an option. Not sure if there is a good workaround for this. I verified this behavior in both RTM and December 2010 Hotfixed versions of SharePoint 2010.

Edit: Just checked the SharePoint 2007 DataFormWebPart.ApplyReceivedFilterData() in Reflector and lo and behold, they did check for DBNull in 2007:

            if (current[str] is DBNull)
                goto Label_006D;
                // Note by myself: Label_006D is the call to MoveNext, aka. continue

Comments (1)

EmanOctober 5th, 2011 at 10:10

Thank you for this valuable post.
It is one thing that Microsoft makes a stupid mistake in the upgrade, but it is much worse when they answer that this is by Design.
What idiot designed this? Do they know something called useability test, ever? or User Acceptance test? It's really proposterous. But this is not the first time Microsoft "improves" a product and creates new stupidities that replace the old ones.
For now, my work-around is to put another instance of the same receiver library but without connection. Can also use Zone Tabs to hide and display whichever of them by tabs.
I'm sure there are other ways too.
Thanks again.