Today’s episode of SharePoint Blank will be unlike any post that’s appeared in this space previously. You see, many the time, I’ve gone into “the mailbag” to pluck a question that allows me to kick off an investigation into learning (and sharing) the answer to the question that had been posed. Today, however, I’d like to hand the reins over to a friend to tell his tale of a SharePoint mystery he’d tripped across… and how he went on to solve that mystery.
A couple of months ago, my friend Bryon Jordan, an IT Analyst/Project Manager in Louisville, KY, dropped me an email informing me that his organization was deploying SharePoint, and he was seeking some recommended resources to help get up to speed on the platform. Well, the other day, I heard from Bryon again, and this time he wanted to share an excellent nugget of SharePoint information that he’d discovered. I thought that Bryon’s discovery (and his telling of it) made for such a great SharePoint story that I wished the discovery had been my own so that I could blog it here … and then I realized, hey, it’s my blog, so if I want to invite a friend to share his own SharePoint Blank-esque tale of discovery in this space, nothing is stopping me from doing so. And so, without further ado, I’m going to get out of Bryon’s way now and let him bring the knowledge…
“I had an exciting SharePoint 2007 experience that I finally solved and thought I’d share it with you. It may be an old hat to you now, but it took a lot of investigating to solve it. It’s funny how no amount of reading ever prepares you as well as rolling up your sleeves and getting your hands dirty.
We create folders for patients using a six-digit number (HIPAA requirements to keep patient confidentiality). Each document in the folder begins with the same number; thus, folder 123456 has any number of documents with names that begin with “123456,” as well as other identifiers to give it a unique name.
When I searched for certain patients (based on their unique identifier), however, information pertaining to other patients also popped up in the search.
I’ve used two fictional patient numbers to illustrate the issue in the following example.
Patient ID 159763 would show six documents in the search results when there were supposed only to be five (not including the parent folder). There was an extra document belonging to patient ID 311789 popping up in the search results that did not have that number at all, although, for some reason, the properties reflected 159763 in the search.
It turns out that SharePoint indexes a lot more than the file name.
After some research, I went into the DB and started doing queries to see if I could find something in the data that triggered the search to display this other patient’s document.
This was my query hitting the views in the SharePoint DB that turned up all sorts of information:
Select the top 20 docs.Leafname, docstreams.* from docs
INNER JOIN docstreams ON docs.ID = docstreams.ID
WHERE docs.LeafName Like ‘311789%’ order leafname
As it turns out, the size of the other patient’s document showing up has a value of 159763 in the field docstreams.size. At least now I know why we have a handful of these unexpectedly popping up throughout our search results.
Better yet, I was able to find a solution to our dilemma.
In Central Administration, go to Shared Services -> Search Settings and click on Metadata Property Mappings.
Scroll down to the “Size” property and click the right-hand column that links to its mapping.
A check box on the bottom right-hand side of the screen named Include values for this property in the search index.
You want to uncheck this. Once you’ve done so, the change apparently takes effect once you re-crawl.”
