Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
DB Engine
SQL ServerMSDESQL Server CE
Services
Analysis (Data Mining)Analysis (OLAP)DTSIntegration ServicesNotification ServicesReporting Services
Programming
CLRConnectivitySQLXML
Other Technologies
ClusteringEnglish QueryFull-Text SearchReplicationService Broker
General
Data WarehousingPerformanceSecuritySetupSQL Server ToolsOther SQL Server Topics
DirectoryUser Groups
Related Topics
MS AccessOther DB ProductsMS Server Products.NET DevelopmentVB DevelopmentJava DevelopmentMore Topics ...

SQL Server Forum / Other Technologies / Full-Text Search / April 2008

Tip: Looking for answers? Try searching our database.

Containstable with Top_n_by_rank returning less than expected rows

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Fredrik - 30 Apr 2008 08:36 GMT
Hi,

Did anyone find a solution to the problem below?

Regards,

Fredrik

---------------

Hello,

I've got a full text index, with an empty noise word file. The table
has only 1 column + 1 timestamp for doing incremental updates (data
changes only once a day, in 1 time). Change Tracking is disabled
(OFF). SQL version is 2005 SP2 (9.0.3054)

From time to time (after a few days), ContainsTable queries with a
Top_n_by_rank clause are returning strange results :

SELECT * FROM CONTAINSTABLE(FullSearch, *, 'the')
=> Returns 12362 rows

SELECT * FROM CONTAINSTABLE(FullSearch, *, 'the', 5000)
=> Returns 569 rows

SELECT * FROM CONTAINSTABLE(FullSearch, *, 'the', 500)
=> Returns 80 rows.

I was expecting the 2nd and 3rd queries to return respectively 5000
and 500 rows, as there are 12362 rows matching the query.

Usually FTS has the correct behavior (returning 5000 and 500 results
for the query 2&3), but from time to time it seems to bug this way.
When this happens, a full or Incremental population, or even
optimizing the catalog without rebuilding it doesn't fix the problem.
In that case, the only method to fix this is to rebuild the catalog,
and the perform a population. And then it will be good for a few days,
and then start again returning less rows than expected.

Is that a known bug from FTS? Is there a way to fix this without
rebuilding the catalog? Thanks.
Hilary Cotter - 30 Apr 2008 11:18 GMT
I believe that occasionally for a few milliseconds during merges the results
can be inaccurate like this-however does this occur regularly and for long
periods?

Why are you using incremental populations. If the bulk of your data changes
at any one time full populations will probably be faster, generally if its
less than 80% of the data an incremental is best - however change tracking
might also work for you. It depends on the amount of data chaning.

> Hi,
>
[quoted text clipped - 38 lines]
> Is that a known bug from FTS? Is there a way to fix this without
> rebuilding the catalog? Thanks.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.