Problem with stoplist word - Inconsistent results when executing a stored procedure from application vs. Management Studio

Question

Hello -

I have a stored procedure that utilizes full-text index searching.   One of the words our users need to include in the search is "other", which is included in the system default stoplist.    When I discovered that "other" was being ignored in the results of the query, I set the stoplist on the table being indexed to "none".    

At that point, the query now returns the correct results when the search term includes the word "other" when I execute it directly from within Sql Server Management Studio.      However, when I issue a call to the stored procedure from my ASP.NET application, using the exact same parameters, it is still behaving as if the stoplist is still active.   I have triple-checked that the parameter values are identical, and I am even hard-coding the database name in my application to ensure that I'm not accidentally picking up a different database.    

An example of this query would be:

exec PHRASE_SEARCH_ALL_WORDS 'fracture', 'humerus', 'upper', 'other'

It's only the word "other" that is returning results incorrectly from the web application.    If I replace "other" with "displaced", for example, the query returns the same results no matter how executed.

We are using SQL Server 2008 R2.   Does anyone have any suggestions?   Thanks in advance for any help!

Answer 1

For such circumstances , perhaps might we have the below assumptions :

There is a defined Thesaurus for Full text index to map some other word that could be applied if used Freetext or Freetexttable commands while Full text search used probably   inside ASP.net application that couldn't be applied if used Contains or containstable commands used probably inside SQL Management studio unless you use explicitly FORMSOF THESAURUS clause.

Please work out this assumption , if still persist , please run profiler on queries coming through Asp.net application and forward results to me a

a

---

Shehap (DB Consultant/DB Architect) Think More deeply of DB Stress Stabilities