We have a library with PDF files that generally have a file name structure like "PN YYYYYYY LN XXXX.pdf" where the Xs and Ys are numerical. There is no other relevant metadata. Searching for a PN (the Y numbers) will not always show all of the results. I can do a search for the LN (the X numbers) and it shows files that have the Y numbers previously searched for that didn't show in the initial search.

An example is this file: PN 1234567 LN TU1234 REC 5000075204.pdf

Searching for "1234567" is showing SOME results with the string IN the filename and also in the document. But not showing the file above. Searching for "TU1234" does show the file. Here are a few other searches I tried and their results:

"PN 1234567" - No
"PN 123*" - No
"PN 1234567 LN TU12*" - No (this one was really surprising)
"PN 1234567 LN TU1234" - Yes
"TU1234" - Yes

  • can you give us the actual file name...you can use differnt numbers – Waqas Sarwar MVP Jul 1 '14 at 6:30
  • I've edited the original post with filename examples. – VincePortalesc Jul 1 '14 at 15:48

I assume that the content of your PDF files is also similar. In this case SharePoint automatically tries to remove duplicate hits by removing some of them.

This feature can be turned of by unchecking the "Remove duplicate results" property of the Search Core Results web part.

This article explains how to do it: http://blog.sharedove.com/adisjugo/index.php/2009/02/11/including-duplicates-in-sharepoint-search-results/

|improve this answer|||||
  • Ok, so when I hover over the file in search results, and click on View Duplicates, it shows the other files which were previously not shown. However, when I check "Show Duplicate File Links", it still doesn't show the proper set. Actually, it strangely enough reversed it. The formerly hidden "duplicate" was the top result, and the former shown result was hidden. – VincePortalesc Jul 1 '14 at 16:49
  • This answer is correct, but only applies to SharePoint 2010. In 2013, I had to export the web part, search for TrimDuplicates (in the JSON properties) and change it from "true" to "false", then upload and add the web part again and it works now. Thanks for your help! – VincePortalesc Jul 1 '14 at 18:21

I've had this issue before when the part being searched for is a number with leading zeroes. so 0000100 would not show up in search results by searching for 100. Since we knew the size of ID we just created a dynamic "000100" or "100" query everytime the search was called.

So my suggestion is to play with the search operators like ", *, AND, OR etc since dealing with numbers is troublesome in search and once finding a working query, injecting it in the querystring / search box to adjust what was typed in by the user.

|improve this answer|||||
  • We don't have any leading zeroes in this case. As you can see in the post, I've tried a lot of different combinations with the * and OR and it doesn't seem to work. Take 2 files, PN 12345 TU1234.pdf and PN 12345 TU1256.pdf. Searching for "12345" shows the first, but not the second. Searching for "12345 OR TU1256" only shows the second! Baffling! – VincePortalesc Jul 1 '14 at 16:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.