Article ID: 312410
Article Last Modified on 9/26/2005
APPLIES TO
- Microsoft SQL Server 2000 Service Pack 3a
This article was previously published under Q312410
BUG #: 355987 (SHILOH_BUGS)
SYMPTOMS
The values returned in the RANK column in full-text search (FTS) queries that use the CONTAINSTABLE or FREETEXTTABLE functions may change when the catalogs repopulate, even if the underlying data does not change.
RESOLUTION
To resolve this problem, obtain the latest service pack for Microsoft SQL Server 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
290211 INF: How To Obtain the Latest SQL Server 2000 Service Pack
NOTE: The following hotfix was created before the release of Microsoft SQL Server 2000 Service Pack 3.
The English version of this fix should have the following file attributes or later:
Build File Version File name Modified Date
---------------------------------------------------------------------
8.00.0564 9.107.6815.4 Tquery.dll Dec 27 2001 4:21:27 AM
NOTE: Because of file dependencies, the most recent hotfix or feature that contains the files may also contain additional files.
This hotfix is designed to be applied to a SQL Server 2000 instance that is running SQL Server 2000 Service Pack 2.
STATUS
Microsoft has confirmed that this is a problem in Microsoft SQL Server 2000.
This problem was first corrected in Microsoft SQL Server 2000 Service Pack 3.
MORE INFORMATION
When this problem appears, the ranking value associated with a given row may be slightly different after a catalog is repopulated. In addition, this change in row ranking may cause small changes in the relative position of a row if the resultset is ordered on the RANK column.
Important: The fix for this problem requires a change in the underlying structure of the full text catalog files. To allow for the catalog format change, the search service immediately initiates a full catalog rebuild the first time you start MSSearch after you apply the hotfix. While the catalog is being rebuilt it does not reflect all of the data in the full-text indexed tables, which means that you should schedule the hotfix installation at a time when you can have the catalog temporarily offline while MSSearch rebuilds the catalog. If there is no such time, another option is to apply the hotfix to a different server with a copy of the production database, and then rebuild the catalog there. Next, apply the hotfix and move the new catalog to the production server. The specific steps for this process are: If this is necessary because a scheduled outage window is not available, then:
- Dump, and then load the database on a SQL Server instance that is running on a secondary server.
- Apply this FTS fix to the secondary server, and then restart MSSearch to initiate a catalog rebuild.
- After the catalog population on the secondary server completes, stop MSSearch on the primary server, and then apply the hotfix.
- Before you restart MSSearch on the production server, use the steps outlined in the "MOVING OR COPYING FT CATALOGS BETWEEN SQL SERVERS" heading of the following Microsoft Knowledge Base article to move the new catalogs from the secondary server to the production server:
240867 INF: How to Move, Copy, and Back Up Full-Text Catalog Folders and Files
After you apply the hotfix, you may notice the following error messages in your Application event log after you restart the MSSearch service. These messages reflect that MSSearch initiated a catalog rebuild due to the catalog format change, and you can ignore the messages when they immediately follow the hotfix installation:
Additional query words: full population
Keywords: kbbug kbfix kbsqlserv2000presp3fix kbqfe kbsqlserv2000sp3fix kbhotfixserver KB312410
