a clause of the query contained only ignored words

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
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.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Andy Fish" <ajfish@.blueyonder.co.uk> wrote in message
news:TdQIc.2174$322.25169020@.news-text.cableinet.net...
> 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
>
|||"Hilary Cotter" <hilaryk@.att.net> wrote in message
news:OQoGdaNaEHA.3016@.tk2msftngp13.phx.gbl...
> 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.
[vbcol=seagreen]
> A freetext search will not generate this error.
> --
> Hilary Cotter
> Looking for a book on SQL Server replication?
> http://www.nwsu.com/0974973602.html
>
> "Andy Fish" <ajfish@.blueyonder.co.uk> wrote in message
> news:TdQIc.2174$322.25169020@.news-text.cableinet.net...
> etc
> letter,
else
>
|||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
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Andy Fish" <ajfish@.blueyonder.co.uk> wrote in message
news:fjYIc.2573$SP6.30587016@.news-text.cableinet.net...
> "Hilary Cotter" <hilaryk@.att.net> wrote in message
> news:OQoGdaNaEHA.3016@.tk2msftngp13.phx.gbl...
> 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[vbcol=seagreen]
> 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?
SQL[vbcol=seagreen]
> yes
rebuild[vbcol=seagreen]
> 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.
>
have[vbcol=seagreen]
catalog[vbcol=seagreen]
'of'
> else
>
|||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
"Hilary Cotter" <hilaryk@.att.net> wrote in message
news:%23%239dvOSaEHA.752@.TK2MSFTNGP09.phx.gbl...
> 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:
"[vbcol=seagreen]
> & objApplications.Count
> for each application in objApplications
> wscript.echo "Application Name: " & application.name
> next
>
> --
> Hilary Cotter
> Looking for a book on SQL Server replication?
> http://www.nwsu.com/0974973602.html
>
> "Andy Fish" <ajfish@.blueyonder.co.uk> wrote in message
> news:fjYIc.2573$SP6.30587016@.news-text.cableinet.net...
> indexed
> the
> only
> As
> uses
> data
> SQL
> rebuild
the
> have
> catalog
> 'of'
>
|||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.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Andy Fish" <ajfish@.blueyonder.co.uk> wrote in message
news:yphJc.3299$AU1.39183567@.news-text.cableinet.net...
> 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[vbcol=seagreen]
> 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
>
>
> "Hilary Cotter" <hilaryk@.att.net> wrote in message
> news:%23%239dvOSaEHA.752@.TK2MSFTNGP09.phx.gbl...
account[vbcol=seagreen]
table[vbcol=seagreen]
> to
SQL_Latin1_General_CP1_CI_AS[vbcol=seagreen]
> FTI
Server:[vbcol=seagreen]
> "
> Server
Server:[vbcol=seagreen]
> "
a[vbcol=seagreen]
and[vbcol=seagreen]
the[vbcol=seagreen]
apparently[vbcol=seagreen]
version.[vbcol=seagreen]
which[vbcol=seagreen]
Files\Microsoft[vbcol=seagreen]
MSSearch.[vbcol=seagreen]
> the
and[vbcol=seagreen]
single[vbcol=seagreen]
anything
>
|||"Hilary Cotter" <hilaryk@.att.net> wrote in message
news:eyOzj5gaEHA.2520@.TK2MSFTNGP12.phx.gbl...
> 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.
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

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