Containstable ranking with pdf-files

Hello all,
it seems to me that ranking of full-text search results does not work
correctly. Here's my scenario:
- one table with a full-text indexed text column and several full-text
indexed meta data columns
- another table with a full-text indexed image column containing .pdf,
..gif, and .jpg files; full-text indexed meta data columns as in the
first table
- a stored procedure that makes a full-text search to the two
full-text indexes (using containstable) and combines the result sets
-Windows 2000 Server, SQL Server 2000 sp3, Adobe PDF iFilter
Now, the search itself seems work as expected. All the rows that
should be returned seem to be returned. The problem is the ranking
with .pdf files: all the .pdf files seem to get a rank value far too
high. A simplified example demonstrates the problem.
TABLE 1
nvc_Heading nvc_Subject txt_Data
Talentless hack missing (long text)
TABLE 2
nvc_Heading nvc_Subject img_Data
Talentless hack missing (binary data)
Making a containstable query to both tables with search term
"talentless hack", the search result from table 1 gets a significantly
lower rank than the result from table 2. It seems that data in column
img_Data is not processed when determining the rank value.
Anyone come across this problem? TIA,
sdr
Recently indexed rows get a higher ranking than rows that have been indexed previously.
Can you change your system time to 1 minute before midnight, wait till the midnight merge occurs and then check to see if the ranking is more consistent.
|||SDR,
Can you confirm if you have "Change Tracking" with "Update Index in
Background" enabled for your FT-enable tables (TABLE 1 and TABLE 2 in your
example)? Also, can you tell us how many rows are in each of these table and
if you're using one FT Catalog for both tables or have one FT Catalog for
each table?
While Hilary suggests changing your server system time, I do not think this
is a good idea as such a change will affect other processes on this server
as well as any date/time sensitive processing for SQL Server table with
datetime columns. An alternative is to change the following Registry key
value (replace <physical_FT_Catalog> your actual FT Catalog folder, for
example: SQL0000500005)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\1.0Ca talogNames\SQLServer\<phys
ical_FT_Catalog>
indexer:ci:MidNightMasterMergeTimeDelta value= <time>
<time> is Time, in minutes, after midnight at which a master merge will
occur. and the default value is 0. Setting <time> to 60, would force the
Master Merge to occur at 1am.
Regards,
John
"Hilary Cotter" <hilaryk@.att.net> wrote in message
news:51F282E4-24EA-4A61-B4A5-CD8B5FA0F622@.microsoft.com...
> Recently indexed rows get a higher ranking than rows that have been
indexed previously.
> Can you change your system time to 1 minute before midnight, wait till the
midnight merge occurs and then check to see if the ranking is more
consistent.
|||Oops, it looks like this problem was fixed with Sp3.
Sorry about that.
Hilary
|||John,
I tried changing the suggested registry value, but no change in
ranking values took place - actually I didn't notice any merge taking
place either.
Change Tracking is not enabled in my database, but I'm running a full
population to both catalogs every night. I suppose the master merge is
done right after the full population, am I correct?
Both tables have their own, dedicated catalogs. There are approx.
15000-20000 rows in each table.
Any more ideas?
sdr
"John Kane" <jt-kane@.comcast.net> wrote in message news:<#IhuyMWOEHA.3312@.tk2msftngp13.phx.gbl>...
> SDR,
> Can you confirm if you have "Change Tracking" with "Update Index in
> Background" enabled for your FT-enable tables (TABLE 1 and TABLE 2 in your
> example)? Also, can you tell us how many rows are in each of these table and
> if you're using one FT Catalog for both tables or have one FT Catalog for
> each table?
> While Hilary suggests changing your server system time, I do not think this
> is a good idea as such a change will affect other processes on this server
> as well as any date/time sensitive processing for SQL Server table with
> datetime columns. An alternative is to change the following Registry key
> value (replace <physical_FT_Catalog> your actual FT Catalog folder, for
> example: SQL0000500005)
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\1.0Ca talogNames\SQLServer\<phys
> ical_FT_Catalog>
> indexer:ci:MidNightMasterMergeTimeDelta value= <time>
>
> <time> is Time, in minutes, after midnight at which a master merge will
> occur. and the default value is 0. Setting <time> to 60, would force the
> Master Merge to occur at 1am.
>
> Regards,
> John
>
>
>
> "Hilary Cotter" <hilaryk@.att.net> wrote in message
> news:51F282E4-24EA-4A61-B4A5-CD8B5FA0F622@.microsoft.com...
> indexed previously.
> midnight merge occurs and then check to see if the ranking is more
> consistent.
|||sdr,
You may have to stop & restart the MSSearch service, for the master merger
change to be effective with changing the registry key value. Could you post
the actual FTS query (containstable or freetexttable) and the rank value
along with the full output of -- SELECT @.@.version -- as this will provide
both SQL Server and OS platform version info.
Regards,
John
"sdr" <viiksi_reima@.hotmail.com> wrote in message
news:3652826d.0405180353.6d3c5ef0@.posting.google.c om...
> John,
> I tried changing the suggested registry value, but no change in
> ranking values took place - actually I didn't notice any merge taking
> place either.
> Change Tracking is not enabled in my database, but I'm running a full
> population to both catalogs every night. I suppose the master merge is
> done right after the full population, am I correct?
> Both tables have their own, dedicated catalogs. There are approx.
> 15000-20000 rows in each table.
> Any more ideas?
> sdr
>
> "John Kane" <jt-kane@.comcast.net> wrote in message
news:<#IhuyMWOEHA.3312@.tk2msftngp13.phx.gbl>...[vbcol=seagreen]
your[vbcol=seagreen]
and[vbcol=seagreen]
for[vbcol=seagreen]
this[vbcol=seagreen]
server[vbcol=seagreen]
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\1.0Ca talogNames\SQLServer\<phys[vbcol=seagreen]
the[vbcol=seagreen]