1

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

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

3 Answers 3

3

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/

2
  • 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. Commented Jul 1, 2014 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! Commented Jul 1, 2014 at 18:21
0

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.

1
  • 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! Commented Jul 1, 2014 at 16:22
0

When you create the file with the name PN 1234567 LN TU1234 REC 5000075204.pdf, As per my understanding the SharePoint creates the following basic indexes and other sequential combinations of these.

PN
1234567
LN
TU1234
REC
5000075204
pdf

To get the file in result you need to provide one of these indexes as a search key.

TU1234 - this will return the result
TU123 - This won't, as no index with this.
TU123* - this works.
*U1234 - this won't, as * can be used only at the end.
TU1234 REC* - This works

Asterisk(*) works only if it's used at the end of the search key.

I am not sure how indexes are created in SharePoint, but here I see it is split by space and dot character. Try to provide the complete words.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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