a clause of the query contained only ignored words

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Andy Fish - 13 Jul 2004 13:05 GMT

Hi,

I don't want any noise words at all for my current application, so have
cleared out the noise.enu file so it is 0 bytes and re-built the catalog

I am pretty sure it is working ok because I can search on 'the' and 'of' etc
which I couldn't do before. however, if I try to search on a single letter,
I still get the old 'only ignored words' error message.

am I hitting on some different limitation here, or is there anything else
that could cause this problem?

thanks in advance

Andy

Reply to this Message

Hilary Cotter - 14 Jul 2004 13:41 GMT

noise.enu is for us english. noise.eng is for the Queens English.

Which word breaker are you using?

Did you edit the noise word lists found in c:\Program Files\Microsoft SQL
Server\MSSQL\FTData\SQLServer\config?

You have to stop MSSearch, make your edits and then restart MSSearch.

Note, to find these noise words in your searches you will have to rebuild
your catalog.

A freetext search will not generate this error.

Signature

Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html

> Hi,
>
[quoted text clipped - 11 lines]
>
> Andy

Reply to this Message

Andy Fish - 13 Jul 2004 22:16 GMT

> noise.enu is for us english. noise.eng is for the Queens English.
>
> Which word breaker are you using?

I wish I knew ;) - is there any way to find out?

when I select @@language it returns "us_english", but the full-text indexed
columns are actually SQL_Latin1_General_CP1253_CI_AI (greek). There is a
small story behind this which may be relevant:

Most of the columns in the database are SQL_Latin1_General_CP1_CI_AS and the
values contain some french acccented characters. When we first built the
text index we wanted it to be accent-insensitive but this is apparently only
possible in the sharepoint version of FTS not in the SQL server version. As
a workaround we created a separate copy of the data to be indexed which uses
the greek character set. Just before the index population, we copy the data
from the CP1 columns into the CP1253 columns which has the effect of
removing all the accents, so the only characters left in AFAIK are us
english ones.

do you think this could be related to the problem?

> Did you edit the noise word lists found in c:\Program Files\Microsoft SQL
> Server\MSSQL\FTData\SQLServer\config?

yes

> You have to stop MSSearch, make your edits and then restart MSSearch.
>
> Note, to find these noise words in your searches you will have to rebuild
> your catalog.

I did all this.

The thing is, before I did this change, a search for "the" would give the
same error but now it works correctly, so I'm pretty sure I edited the
correct noiselist and rebuilt the catalog correctly.

> A freetext search will not generate this error.
> > Hi,
[quoted text clipped - 14 lines]
> >
> > Andy

Reply to this Message

Hilary Cotter - 14 Jul 2004 22:53 GMT

in your full text enabled database issue a

sp_MShelpcolumns 'FullTextIndexedTableName'

the last column will give you a number 1033 is for US_English

You can always issue a
exec master..xp_MSFullText
to get a list of the languages and the LocaleID's which are the numbers
returned in the last column of the sp_MShelpcolumns call.

From what you describe about the history of your database it might account
for this behavior. To verify this you will probably have to DTS the table to
another table in this database which uses the SQL_Latin1_General_CP1_CI_AS
collation. Then try to reproduce these results with this table when you FTI
it.

Purely for diagnostic reasons could you run this on your SQL Server:

Set objSearchAdmin=CreateObject("MSSearch.Admin")

Set infoNT=CreateObject("WinNTSystemInfo")

wscript.echo"Host Name: "& objSearchAdmin.HostName

objSearchAdmin.HostName =InfoNT.ComputerName
Set objApplications=objSearchAdmin.Applications
wscript.echo "Number of Search Applications serviced by this Build Server: "
& objApplications.Count
for each application in objApplications
wscript.echo "Application Name: " & application.name
next

Purely for diagnostic purposes could you run this script on your SQL Server

Set objSearchAdmin=CreateObject("MSSearch.Admin")

Set infoNT=CreateObject("WinNTSystemInfo")

wscript.echo"Host Name: "& objSearchAdmin.HostName

objSearchAdmin.HostName =InfoNT.ComputerName
Set objApplications=objSearchAdmin.Applications
wscript.echo "Number of Search Applications serviced by this Build Server: "
& objApplications.Count
for each application in objApplications
wscript.echo "Application Name: " & application.name
next

Signature

Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html

> > noise.enu is for us english. noise.eng is for the Queens English.
> >
[quoted text clipped - 53 lines]
> > >
> > > Andy

Reply to this Message

Andy Fish - 14 Jul 2004 22:17 GMT

Hilary,

sorry the turnaround on this is so slow but this isn't my day job so I have
to work odd hours at it.

I did the MShelpcolumns and it returned 1033 as expected. I also ran the VBS
script and it said there was just one search application, namely SQL Server

More interestingly, I created a couple of test tables, one with CP1253 and
one with the default CP1, in a brand new database and new full text catalog.
both tables exhibited the same symptoms as my original problem i.e. I can
search for 'the' but not 'a'

I then tried the same process on a different machine (again with an empty
noise.enu) and both searches worked i.e. the result I was looking for.

I noticed that the original machine was only on SQL 2000 SP2, so I upgraded
it to SP3. However, this doesn't seem to have fixed the problem.

so at the moment I have two machines, the non-working one is win2k server
sp4 running sql server 2000 standard sp3, and the working one is winxp sp1
running sql server 2000 developer sp3. both are using us english word
breaker and an empty noise.enu file.

do you have any idea what other difference might be causing this problem?
The non-working machine has quite a lot of other stuff installed on it but
nothing that I can think would interfere

Andy

> in your full text enabled database issue a
>
[quoted text clipped - 113 lines]
> > > >
> > > > Andy

Reply to this Message

Hilary Cotter - 15 Jul 2004 02:53 GMT

Did you run a full population?

Just to make sure I have this correct, you can now search on 'a' and 'the'
without getting the 'a clause in the query only contained ignored words.',
but you can't get hits to rows that contain 'a' and 'the'?

Also you should not have a 0 byte noise word file. It should contain 1 byte
or a blank space.

Signature

Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html

> Hilary,
>
[quoted text clipped - 149 lines]
> > > > >
> > > > > Andy

Reply to this Message

Andy Fish - 15 Jul 2004 15:19 GMT

> Did you run a full population?
>
[quoted text clipped - 4 lines]
> Also you should not have a 0 byte noise word file. It should contain 1 byte
> or a blank space.

YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!!

:-))))))))))))))))))))))))))))))))))))))))))))))))

sorry - excluse my julilation - that was the solution.

my noise file was 0 bytes long. putting a blank space in the noise file and
re-indexing causes it to work correctly.

Just to recap on the symptoms as the previous email maybe wasn't clear
enough. with a 0 byte noise file, it's possible to correctly search on 'the'
or any normal noise word, but searching for a single letter term gave the
error about 'a clause of the query contained only ignored words'. With a
noise file containing a blank like, a search for a single letter works
correctly. Everything about the character sets/word breakers and the service
pack was irrelevant in this case.

Thank you very much for your help in this case - I don't know how I would
have found it otherwise. Now I know what to search for, I have found a bit
of other discussion about this topic on the net.

Andy

Reply to this Message