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 / September 2006

Tip: Looking for answers? Try searching our database.

Must a hyphen always be a wordbreaker?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
John Loveland - 08 Feb 2006 20:22 GMT
My clients need to be able to search on identification numbers that are
formatted like '5-1' or '10-23'.  In the first instance, I can't do it at
all, because the wordbreaker breaks 5 and 1 apart, then ignores both as
noise words.  In the second case, I get a bunch of stuff back that has 10
and 23.  I'd like to be able to search for that particular string without
breaking it apart.  My issue is only with hyphens - not any other
non-numeric characters.

Thanks for your help
--John Loveland
Hilary Cotter - 08 Feb 2006 20:47 GMT
Remove the numbers from your noise word lists and then rebuild your
catalogs. Then change the hyphen to HYPEN in your content, i.e. 5-1 becomes
5HYPHEN1, and 10-23 becomes 10HYPEN23. Then when you search on 10-23 change
the search to 10HYPEN23 and if you are displaying your content, correct it
on the fly.
Signature

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

Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com

> My clients need to be able to search on identification numbers that are
> formatted like '5-1' or '10-23'.  In the first instance, I can't do it at
[quoted text clipped - 6 lines]
> Thanks for your help
> --John Loveland
mjr111 - 11 Sep 2006 17:02 GMT
Replacing the term 10-23 with 10HYPHEN23 seems a pretty poor wor
around. Especially considering it used to work correctly with SQL20
and windows 2000.

Why have MS changed this, or at least when will they accept it is a bu
with windows 2003 and fix it. It seems it's something to do with the O
and not actually SQL2005.. or some strange combination of both.

The old version worked as you would expect, a term indexed as 14314
could be found by searching for 143-143, or 143143. In other words i
would act as a word 'joiner'. However a term indexed as 21-2100 coul
only be found by searching for that.

In terms of grammer and logic the old way makes more sense, a hyphen i
meant to join two works, not break them.

This change has pretty much made SQL server useless for my entir
ecommerce application as part numbers can have hyphens in so if anyon
has any other suggestions i'd love to hear the

--
mjr11
Hilary Cotter - 11 Sep 2006 19:11 GMT
Microsoft changed the word breaker between versions. I don't know of a way
other than what I have suggested to fix this.

Signature

Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.

This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.

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

Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com

> Replacing the term 10-23 with 10HYPHEN23 seems a pretty poor work
> around. Especially considering it used to work correctly with SQL200
[quoted text clipped - 15 lines]
> ecommerce application as part numbers can have hyphens in so if anyone
> has any other suggestions i'd love to hear them
 
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.