n8d

* Update: The official description to this problem can be found in the Knowledgebase Article KB2596519. There is also a hotfix avaliable that can be downloaded here. A big thanks to the Microsoft Support Team. *

One of my customers stumbles upon a strange bug in SharePoint that relies on the list views in combination with meta data and the meta data Navigation. In a special case the list view returns a false result.

The Problem

To reproduce this problem a standard document library is needed. This library has two managed meta data columns named “Color” and “Horse Power”. Both columns allow multiple values, which make sense for car descriptions to find cars by different colors and different horse power.

The values for the colors are:

• Dark
  • Black
    • Black / White
    • Black / Green
    • Black / Red
    • Black / Pink
    • Black / White

• Darkblue
• Darkgreen

• …
• Light

• …
• Metallic

• …

The values for horse power are:

• Less than 50
• 50 – 100 PS
• 101 – 200 PS
• 201 – 300 PS

The document library contains more than 170 items, which has all metadata assigned. The document library has metadata navigation enabled. The document library looks like this:

Document Library with meta data

In general there is no problem browsing the documents and paging. The filtering also works correct but not in all cases. The problem occurs if specific values for colors with all descendants and horse power will be selected. The result will then look like this:

Filter returns false result in list view

The item count of the view shows that 507 items will be returned by SharePoint but only seven items will be displayed. Paging also is not present because the view only displays seven items. The problem with this query is that the item count doesn’t count the returned items. Instead the returned terms of the metadata store will be counted and displayed. The correct result for this query should be 141 items. The calculation to get to 507 returned item looks like this.

141*3+84 = 507

141 by 3 is because they have all the same meta-data assigned plus 84 items has additional terms assigned. Simple calculation but a wrong result in any case.

Filtering by using metadata navigation is one possibility, but the same thing happens if the filtering will be done using the view headers. The result looks then the same:

Filtering using List View Header

A combination of list view header and meta-data navigation filtering will also output the same false result.

The Reason

The problem has nothing to do with the meta-data navigation control, the meta-data or the XSLT List View itself. The reason for this is that SharePoint executes a wrong SQL query against the database and returns then a wrong result back to the SharePoint user interface. I think there must be somewhere a wrong join in the Database. The values here don’t match to a real world scenario but filtering like this is a requirement in one of my SharePoint Applications. I think filtering like this is a common task in a document management system and should work.

The Resolution

The good news is that Microsoft confirms this as an offically bug and the solution is scheduled for the October CU. The lesson I learned from this is: Always open bug report like this to Microsoft and don’t let it be just a bug. The people at Microsoft were really helpful in this case. Cannot wait to get October CU. Currently the solution will be excessively tested.