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:
- Black / White
- Black / Green
- Black / Red
- Black / Pink
- Black / White
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:
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:
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:
A combination of list view header and meta-data navigation filtering will also output the same false result.
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 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.