The process described in the KB article you linked doesn't actually perform the re indexing, it only clears the flags that indicate each item has been indexed. By following the steps in the KB article, you are effectively telling the background indexing process to reindex every item.

How long did you wait between running the provided SQL queries and testing the search again? It is possible that the indexing thread was still processing items when you performed your last search.

You should also keep in mind that while performing a reindex, the background thread will ignore any words that occur in at least 50% of items being indexed. This means that if the word "pronto"  occurs in at least half of your KB articles - regardless of case - that word will not be indexed.

Hi Andrew, Yes we were aware that the reindexing process should trigger after following the KBA and that it would take some time to run through the process. We ran the process about 1 and a half days ago but nothing has changed in the search for that word. This is the only KBA with the word Pronto in it.

Just for an experiment... I created another KBA and used the wording "wherefore art thou Pronto". Searching for the word Pronto shows nothing. Searching for the word "thou" or "wherefore" returns the KBA. 

What can be wrong with the word pronto?

Thanks

Steven

Does anyone have any ideas to make the magic happen in KBA search results. It is like the Search algorithm in smartertrack is ignoring this key word but performing correctly on others so we know it is running and the KBA has been indexed by smartertrack. From the looks of it there is no way to allocate Key words against a article so we are stuck with the product not performing as documented for the search capabilities.

Are there any further suggestions on this Andrew?
This is continuing to impact us and prevent users from finding relevant articles. These keywords are not occurring in more than half of the articles, so I do not see why they would be filtered. Is there a way to set keywords for an article manually?

Steven -

Unfortunately, we have been unable to recreate your issue in internal testing. At this point, the only suggestion I have remaining is to try submitting a ticket so that we can collect some additional information from your installation. 

We have opened up a support ticket and working through the process with the team.

Steven, the ability to edit/adjust the noise list has been added to our feature list for consideration in the future. Keep an eye out for release notes dealing with this area for updates. 

Hi Kyle

Thanks. I would prefer that it was not on a "consideration list" as the search function just does not work adequately for us and other customers due to an undocumented feature call the Noise List that is hard coded. This is more of a bug against the product documentation for the search feature in ST and the search is not working from a cust/user perspective as per the documented feature of search. It needs to be exposed via the front end or at least accessible in the DB or flat file so customers can impact the searches that are not working for them. Unless you are suggesting to keep an eye on the release notes because you know the dev team is actually fixing the problem?? In that case i would be very happy to hear that we will get some movement on this long running search issue.

Thanks

Steven 

Steven, I definitely understand your thoughts on this and I will ping our dev team during our next review meeting to see if they would be open to reconsidering the type of request this is entered as. Either way though I'll see if I can put some priority on this for you.