Does SQLSERVER support fuzzy text searching(like the function of agrep).

Does SQLSERVER support fuzzy text searching(like the function of agrep).
For example, given the input keyword [homogenos] and similarity
parameter [2 characters], the function will find out valid result from
datasource by either replacing,inserting or deleting upto two different
characters from word [homogenos].
Both homogenooos(homogeno[+oo]s) and homogeos(homoge[-n]os are valid
result.
thx.No, not directly. You need to build a function that does Levenstein Edit
distance. You will find an implementation of this in the Fuzzy functions
which ship with SSIS in SQL 2005.
You can also use the expansion options in the thesaurus capabilities in
FullText search so a search on homogenos could be expanded to search on
homogenos homogenoos, homogeneous or homogeos, but you have to know in
advance what all the expansions might be and hard code them into your
thesaurus file.
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
"zlf" <zlfcn@.hotmail.com> wrote in message
news:uGyRG55YGHA.4944@.TK2MSFTNGP02.phx.gbl...
> Does SQLSERVER support fuzzy text searching(like the function of agrep).
> For example, given the input keyword [homogenos] and similarity
> parameter [2 characters], the function will find out valid result from
> datasource by either replacing,inserting or deleting upto two different
> characters from word [homogenos].
> Both homogenooos(homogeno[+oo]s) and homogeos(homoge[-n]os are valid
> result.
> thx.
>

Does SQLSERVER support fuzzy text searching(like the function of a

functions are
SOUNDEX
DIFFERENCE
For freetext, try contains clause,
check CONTAINS in BOL
I hope this was what u were asking forThank you for your reply.
However, as I know, CONTAINS does not support the kind of fuzzy searching
described in my post.
And it is very likely that it does support it and I do not know how to use
it.
Can u show my a sample? Thank you again.
-- Original Message --
From: "Omnibuzz" <Omnibuzz@.discussions.microsoft.com>
Newsgroups: microsoft.public.sqlserver.programming
Sent: Wednesday, April 19, 2006 7:00 PM
Subject: RE: Does SQLSERVER support fuzzy text searching(like the function
of a
"Omnibuzz" <Omnibuzz@.discussions.microsoft.com> д?:43C1F9E4-4CA3-478D-9064-82AA8D
9DA35D@.microsoft.com...
> functions are
> SOUNDEX
> DIFFERENCE
> For freetext, try contains clause,
> check CONTAINS in BOL
> I hope this was what u were asking for|||Thank you for your reply.
However, as I know, CONTAINS does not support the kind of fuzzy searching
described in my post.
And it is very likely that it does support it and I do not know how to use
it.
Can u show my a sample? Thank you again.
-- Original Message --
From: "Omnibuzz" <Omnibuzz@.discussions.microsoft.com>
Newsgroups: microsoft.public.sqlserver.programming
Sent: Wednesday, April 19, 2006 7:00 PM
Subject: RE: Does SQLSERVER support fuzzy text searching(like the function
of a
"Omnibuzz" <Omnibuzz@.discussions.microsoft.com> д?:43C1F9E4-4CA3-478D-9064-82AA8D
9DA35D@.microsoft.com...
> functions are
> SOUNDEX
> DIFFERENCE
> For freetext, try contains clause,
> check CONTAINS in BOL
> I hope this was what u were asking for

Does SQL2005 still require all FTI keywords to match in the same column?

Hello,
My understanding of full-text index searching is that CONTAINS()
requires that all the keywords supplied (separated by AND) must match
in the same column in order for the record to be considered a match and
returned. So if we have a situation where we need keywords to match in
multiple columns, we either need to use multiple CONTAINS() statements,
use FREETEXT() and allow it to manipulate our keywords, or create a
single column containing all the text we want indexed for a row and
search that unified column.
Is this correct? If so, is this shortcoming fixed in SQL2005?
Thanks,
Thomas
Hi Thomas,
I am afraid SQL 2005 shows the same behavior. FTS is designed to search for text/documents, which normally are stored in the same column. Can you please explain a bit more why you need to have queries that involve several word matches for several columns?
Thanks!
Fernando Azpeitia Lopez,
Program Manager
SQL Server FTS team
--Original Message--
From: Thomas
Posted At: Wednesday, February 15, 2006 9:33 AM
Posted To: microsoft.public.sqlserver.fulltext
Conversation: Does SQL2005 still require all FTI keywords to match in the same column?
Subject: Does SQL2005 still require all FTI keywords to match in the same column?
Hello,
My understanding of full-text index searching is that CONTAINS()
requires that all the keywords supplied (separated by AND) must match
in the same column in order for the record to be considered a match and
returned. So if we have a situation where we need keywords to match in
multiple columns, we either need to use multiple CONTAINS() statements,
use FREETEXT() and allow it to manipulate our keywords, or create a
single column containing all the text we want indexed for a row and
search that unified column.
Is this correct? If so, is this shortcoming fixed in SQL2005?
Thanks,
Thomas
|||Hi Fernando,
I'm not sure exactly how to respond... SQL Server excels at storing all
kinds of data. Our records are hybrids of large text fields, numbers,
dates, etc. We have multiple text columns. Just as one example, let's
say we have an email database where we have the headers stored in
different fields, at the very least, subject and body in different
fields. A person enters multiple keywords, and even if some are in the
subject and some are in the body, the record should match. That's just
a basic example.
We were really blown away when we found out this does not behave in
this fashion. It makes no sense, from our perspective as a user, to
query * (all columns) for some keywords, and require they all match in
only a single column.
Another problem we are fighting that lends itself to being allowed to
find the keywords across columns: tagging. We have found that we can
really speed up our searches if the entire search is performed on the
FTS side of the equation.
Contrived Example: You want to find all records that contain the word
"house" and were created in September 2005. Your table holds 100,000
records. Let's say 50,000 of those records contain the word "house."
But only 1000 were created in September 2005. You could do a search
like this:
SELECT * FROM ourtable WHERE CONTAINS(*, '"house"') AND createdate
BETWEEN '09/01/2005 00:00:00' AND '09/30/2005 23:59:59'
But we have found this search is really slow. The slowdown is in the
number of records being returned that contain "house" even though most
of them are not going to pass our SQL Server filter of the date. So we
want to create a tag column of textual things that we can search on the
FTS. Then our query would be:
SELECT * FROM ourtable WHERE CONTAINS(*, '"house" and "DT200509"')
Now we've shifted the date requirement over to the FTS side of the
search. Admittedly, a hack, but it should work. As you know, it
doesn't, because the two keywords will be found in two different
columns.
So what we are forced to do now is the ultimate hack: create a single,
new text field where we are duplicating all of our data from multiple
columns, adding our "tags" for constraining the searches, and then
full-text indexing this single column in order to get fast searches.
It seems weird that FTS is designed to search documents when SQL Server
is designed to hold all kinds of data. Shouldn't FTS be designed to
efficiently search what SQL Server can hold?
Thanks for your time.
Regards,
Thomas
|||Hi Thomas,
I see your problem. Let me think about the best solutions.
Most of FTS users are focus in get great functionality to efficiently search inside a document, rather than to search parts in different documents stored in different columns. Anyway, for these cases like yours, we support multiple CONTAINS. Is true that
the performance is not as good as with one single CONTAINS but if we would allow from the beginning to have several columns look ups in a single CONTAINS, we would probably finish with similar performance even if you are just writing one clause.
The good news is the following.
-For next FTS release we have several architecture improvements that will improve dramatically the joined queries. This means that mix relational (date for instance) with FTS search will be efficient. Following your example, before look the FTS side, the
optimizer will get the few ones that pass the date filter and then these ones will be FT searched.
This improvement also will improve multiple CONTAINS queries, so you will not longer experiment pain.
-For now, the best you can do is to use computed columns. These columns will contain virtually the same data than the original columns and you can create a FT index on that column. The indexing time will take longer as you are merging 2 or more columns bu
t at query time you will be able to query efficiently and find what you look for.
Does this help?
Regards,
Fernando Azpeitia Lopez,
Program Manager
SQL Server FTS team
--Original Message--
From: Thomas
Posted At: Wednesday, February 15, 2006 9:34 PM
Posted To: microsoft.public.sqlserver.fulltext
Conversation: Does SQL2005 still require all FTI keywords to match in the same column?
Subject: Re: Does SQL2005 still require all FTI keywords to match in the same column?
Hi Fernando,
I'm not sure exactly how to respond... SQL Server excels at storing all
kinds of data. Our records are hybrids of large text fields, numbers,
dates, etc. We have multiple text columns. Just as one example, let's
say we have an email database where we have the headers stored in
different fields, at the very least, subject and body in different
fields. A person enters multiple keywords, and even if some are in the
subject and some are in the body, the record should match. That's just
a basic example.
We were really blown away when we found out this does not behave in
this fashion. It makes no sense, from our perspective as a user, to
query * (all columns) for some keywords, and require they all match in
only a single column.
Another problem we are fighting that lends itself to being allowed to
find the keywords across columns: tagging. We have found that we can
really speed up our searches if the entire search is performed on the
FTS side of the equation.
Contrived Example: You want to find all records that contain the word
"house" and were created in September 2005. Your table holds 100,000
records. Let's say 50,000 of those records contain the word "house."
But only 1000 were created in September 2005. You could do a search
like this:
SELECT * FROM ourtable WHERE CONTAINS(*, '"house"') AND createdate
BETWEEN '09/01/2005 00:00:00' AND '09/30/2005 23:59:59'
But we have found this search is really slow. The slowdown is in the
number of records being returned that contain "house" even though most
of them are not going to pass our SQL Server filter of the date. So we
want to create a tag column of textual things that we can search on the
FTS. Then our query would be:
SELECT * FROM ourtable WHERE CONTAINS(*, '"house" and "DT200509"')
Now we've shifted the date requirement over to the FTS side of the
search. Admittedly, a hack, but it should work. As you know, it
doesn't, because the two keywords will be found in two different
columns.
So what we are forced to do now is the ultimate hack: create a single,
new text field where we are duplicating all of our data from multiple
columns, adding our "tags" for constraining the searches, and then
full-text indexing this single column in order to get fast searches.
It seems weird that FTS is designed to search documents when SQL Server
is designed to hold all kinds of data. Shouldn't FTS be designed to
efficiently search what SQL Server can hold?
Thanks for your time.
Regards,
Thomas
|||Fernando Azpeitia Lopez wrote:

> The good news is the following.
> -For next FTS release we have several architecture improvements that will improve
>dramatically the joined queries. This means that mix relational (date for instance) with
>FTS search will be efficient. Following your example, before look the FTS side, the
>optimizer will get the few ones that pass the date filter and then these ones will be FT
>searched. This improvement also will improve multiple CONTAINS queries, so you will
>not longer experiment pain.
When you say the "next FTS release," does this mean an upgrade to SQL
2005's FTS, or do you mean the FTS that is released in whatever version
comes after SQL Server 2005 (i.e. SQL Server 2010 ;-)

> -For now, the best you can do is to use computed columns. These columns will
>contain virtually the same data than the original columns and you can create a FT index
> on that column. The indexing time will take longer as you are merging 2 or more
>columns but at query time you will be able to query efficiently and find what you look
>for.
Can you give me an example of how to do a FTI on a computed column? We
are currently using SQL Server 2000, and only preparing our move to
2005, so are not yet familiar with 2005 completely.
Thanks,
Thomas
|||Hi Thomas,
When I say next FTS release I mean the next release, not any upgrade. And don’t worry, the next version should be no longer than 2007
In a following post I will let you know the steps to work with computed columns in SQL 2005.
Regards,
Fernando Azpeitia Lopez,
Program Manager
SQL Server FTS team
--Original Message--
From: Thomas [mailto:tomwinzig@.gmail.com]
Posted At: Friday, February 17, 2006 10:50 AM
Posted To: microsoft.public.sqlserver.fulltext
Conversation: Does SQL2005 still require all FTI keywords to match in the same column?
Subject: Re: Does SQL2005 still require all FTI keywords to match in the same column?
Fernando Azpeitia Lopez wrote:

> The good news is the following.
> -For next FTS release we have several architecture improvements that will improve
>dramatically the joined queries. This means that mix relational (date for instance) with
>FTS search will be efficient. Following your example, before look the FTS side, the
>optimizer will get the few ones that pass the date filter and then these ones will be FT
>searched. This improvement also will improve multiple CONTAINS queries, so you will
>not longer experiment pain.
When you say the "next FTS release," does this mean an upgrade to SQL
2005's FTS, or do you mean the FTS that is released in whatever version
comes after SQL Server 2005 (i.e. SQL Server 2010 ;-)

> -For now, the best you can do is to use computed columns. These columns will
>contain virtually the same data than the original columns and you can create a FT index
> on that column. The indexing time will take longer as you are merging 2 or more
>columns but at query time you will be able to query efficiently and find what you look
>for.
Can you give me an example of how to do a FTI on a computed column? We
are currently using SQL Server 2000, and only preparing our move to
2005, so are not yet familiar with 2005 completely.
Thanks,
Thomas

Does indexing on IMAGE fields work?

I am doing some prototyping using FTS in SQL 2005 Standard and am having
serious problems getting searching to work when using IMAGE or VarBinary(max)
fields. The index sortof works when using varchar fields. The only problem
with varchar is that it doesn't seem to always auto popluate when I make a
change (see other posting "FT Index doesn't Auto Populate"). However, when
trying the same thing with Image fields loaded with RTF data, the search
always returns nothing. The crawl log shows an error when indexing is first
done; (Error '0x80004005' ), however, it states that it will attempt to
reindex. The log shows 3 more attempts which fail and then finally one that
seems to succeed showing 6 records processed and 0 failed. Aside from that,
there is no other indication of a failure in any of the steps.
Some things I've tried;
- I've upgraded to SP1
- I'm always careful to enable the index after creating it (a new feature in
SP1)
- I've tried loading the DocType field for the associated image field with
several different types (doc, rtf, txt) and tried loading all three types of
documents into the image field. None work
- I've confirmed the iFilters are loaded on this server (eventhough I know
they should be there anyway as preloaded filters)
- I've created an index on a varchar(100) field that is in this same
database and table. The indexing and searching work fine, so, we know
there's nothing odd about the FTS, database, or table
Here's one of the basic queries I use to do the search, although, I've tried
several variations (none work)
SELECT Resume
FROM tbl_ServiceProviders
WHERE CONTAINS(Resume, ' "a*" ');
Having no practical experience with this Microsoft FTS feature, the obvious
question I'm starting to consider; Is this product ready for primetime? Has
anyone gone to production with SQL 2005 FTS? I'm being asked to use this to
build a search feature for an existing "job candidate searching system". I'm
getting a little concerned.
Thanks in advance for any insights anyone can offer
Mike
Maz
Have you looked at the full-text crawl logs? Also make sure the value of the
type column corresponds to the actual file type in the varbinary/image column.
See if this helps:
http://milambda.blogspot.com/2005/12/ifilter-error-bydesign-or-bybug.html
BTW, when searching for "a*" are you searching or words beginning with the
letter a? If you do, try again without the double quotes.
ML
http://milambda.blogspot.com/
|||Thanks ML for directing me to the article. Unfortunately, I've considered
all those elementary suggestions already.
I'm very frustrated with this product. I haven't even started implementing
a business solution for this yet! I'm just trying to do some very basic
prototyping and can't get 1) cataloging jobs to run, 2) auto populate to work
in realtime on a consistent basis, 3) Image fields to index.
Of course you might be thinking I might be a moron. I've considered that
myself However, I can assure you I am not. I've been programming for 20+
years and working with SQL Server for 10 years. I've never had such a hard
time performing basic prototyping using the provided technical documentation.
My conclusion so far; this product is terrible. It probably works, but you
need the "real world" manual to be productive with it. Unfortunately, it
seems so few people are using this product that there doesn't seem to be a
book available to offer real practical advice. The MS documentation only
instructs you on the theoretical behavior of this product. I can only
imagine the problems we will run into in a production environment with this.
Anyone know of any books based on practical experience using SQl 2005 FTS?
If not, I'm considering looking elsewere for my full text search needs.
Mike
"ML" wrote:

> Have you looked at the full-text crawl logs? Also make sure the value of the
> type column corresponds to the actual file type in the varbinary/image column.
> See if this helps:
> http://milambda.blogspot.com/2005/12/ifilter-error-bydesign-or-bybug.html
> BTW, when searching for "a*" are you searching or words beginning with the
> letter a? If you do, try again without the double quotes.
>
> ML
> --
> http://milambda.blogspot.com/
|||Spicy wrote on Sat, 3 Feb 2007 12:55:09 -0800:

> Having no practical experience with this Microsoft FTS feature, the
> obvious question I'm starting to consider; Is this product ready for
> primetime? Has anyone gone to production with SQL 2005 FTS? I'm being
> asked to use this to build a search feature for an existing "job candidate
> searching system". I'm getting a little concerned.
This bit I can answer - I've been using SQL 2005 FTS on public websites
since Feb 2006, and prior to that SQL 7 FTS for a few years (we skipped 2000
on our web sites, but use 2000 FTS internally). If you check http://www.compman.co.uk
, http://www.bookfellas.co.uk , or http://www.sprintbooks.co.uk , all
searches for keywords are done using FTS on SQL 2005. This is running on a
database with almost 700,000 products, and with FTIs on various columns for
each product.
Dan
|||That's somewhat conforting to hear. I suppose I'll keep trying to search the
internet for instances of this happening. I'm following the instructions
exactly. It just won't work for me. I've even tried changing the doc type
to include the dot because I saw it used both ways in some examples (e.g.
"rtf" and ".rtf") Nothing seems to work.
Maz
"Daniel Crichton" wrote:

> Spicy wrote on Sat, 3 Feb 2007 12:55:09 -0800:
>
> This bit I can answer - I've been using SQL 2005 FTS on public websites
> since Feb 2006, and prior to that SQL 7 FTS for a few years (we skipped 2000
> on our web sites, but use 2000 FTS internally). If you check http://www.compman.co.uk
> , http://www.bookfellas.co.uk , or http://www.sprintbooks.co.uk , all
> searches for keywords are done using FTS on SQL 2005. This is running on a
> database with almost 700,000 products, and with FTIs on various columns for
> each product.
> Dan
>
>
|||So, there are no errors in the crawl log?
ML
http://milambda.blogspot.com/
|||Take a look at my first post on this thread. There is an error that states
it will retry to index. It retries (and fails) several times, then it
finally succeeds and says that 6 rows were indexed and 0 failed. That was
the only thing that seemed exceptional. However, since it finally stated
that the index succeeded, I assumed that was not the problem. FYI: There
arre 100 records in the test database and 6 rows with data in the image
field. The reported numbers seem to match up with what I expected to see
Maz
"ML" wrote:

> So, there are no errors in the crawl log?
>
> ML
> --
> http://milambda.blogspot.com/
|||We index over 2 terabytes. It works well for us. The 4005 error is a generic
access denied, it could be caused by several factors. Can you try to extract
your data as text and index it that way? I would also remove a from your
noise word list and rebuild your catalog to remove the possibility that that
is causing your problems.
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
"Spicy Mikey" <Maz@.newsgroups.nospam> wrote in message
news:10663BF1-D3E4-4D58-8D7E-B1C9B325B5BB@.microsoft.com...
>I am doing some prototyping using FTS in SQL 2005 Standard and am having
> serious problems getting searching to work when using IMAGE or
> VarBinary(max)
> fields. The index sortof works when using varchar fields. The only
> problem
> with varchar is that it doesn't seem to always auto popluate when I make a
> change (see other posting "FT Index doesn't Auto Populate"). However,
> when
> trying the same thing with Image fields loaded with RTF data, the search
> always returns nothing. The crawl log shows an error when indexing is
> first
> done; (Error '0x80004005' ), however, it states that it will attempt to
> reindex. The log shows 3 more attempts which fail and then finally one
> that
> seems to succeed showing 6 records processed and 0 failed. Aside from
> that,
> there is no other indication of a failure in any of the steps.
> Some things I've tried;
> - I've upgraded to SP1
> - I'm always careful to enable the index after creating it (a new feature
> in
> SP1)
> - I've tried loading the DocType field for the associated image field with
> several different types (doc, rtf, txt) and tried loading all three types
> of
> documents into the image field. None work
> - I've confirmed the iFilters are loaded on this server (eventhough I know
> they should be there anyway as preloaded filters)
> - I've created an index on a varchar(100) field that is in this same
> database and table. The indexing and searching work fine, so, we know
> there's nothing odd about the FTS, database, or table
> Here's one of the basic queries I use to do the search, although, I've
> tried
> several variations (none work)
> SELECT Resume
> FROM tbl_ServiceProviders
> WHERE CONTAINS(Resume, ' "a*" ');
>
> Having no practical experience with this Microsoft FTS feature, the
> obvious
> question I'm starting to consider; Is this product ready for primetime?
> Has
> anyone gone to production with SQL 2005 FTS? I'm being asked to use this
> to
> build a search feature for an existing "job candidate searching system".
> I'm
> getting a little concerned.
> Thanks in advance for any insights anyone can offer
> Mike
>
>
> --
> Maz
|||Spicy wrote on Mon, 5 Feb 2007 06:01:02 -0800:

> That's interesting about the 4005 being an access problem. I wonder if
> all these problems are related to the same thing. In my other thread I
> talked about not being able to create the catalog job. It tells me it
> can't connect to the server remotely and suggested I be sure to have
> "remote access" turned on. I'm sure that's not the problem. I can access
> the database from my application using oledb and a standard connection
> string. I'm trying to creat the catalog from SMSS and am logged on as
> "sa".
I have no problems with SMSS or EM (for 2000/7), I am logged onto an account
on my local machine that exists as an admin on the SQL Server machine (it's
on a DMZ, not in our ADS, hence having to setup an account on the SQL
machine for me to admin it). It sounds as though you might have a problem
with the NTLM side of things - remember, the 'sa' login via SMSS is only for
SQL Server itself - communication with the Search service that is FTS is via
the NT subsystem itself, so you'll require your local login credentials to
match an admin level (or one that's able to communicate with the Search
service) credential on the SQL Server machine.
Dan
|||It is reported as an generic access problem, but it could be something
entirely different.
If you want to send me sample docs off line, I'll try to repro your problem.
We might get to the bottom of it faster this way.
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
"Spicy Mikey" <Maz@.newsgroups.nospam> wrote in message
news:CA379695-8D0C-46E7-8C65-F0F0AE6C5153@.microsoft.com...[vbcol=seagreen]
> That's interesting about the 4005 being an access problem. I wonder if
> all
> these problems are related to the same thing. In my other thread I talked
> about not being able to create the catalog job. It tells me it can't
> connect
> to the server remotely and suggested I be sure to have "remote access"
> turned
> on. I'm sure that's not the problem. I can access the database from my
> application using oledb and a standard connection string. I'm trying to
> creat the catalog from SMSS and am logged on as "sa".
> By the way, I tried several different search strings, not just "a*".
> That's
> not the problem. Rest assured, I've tried anything obvious and logical.
> Since FTS works great for you, I am assuming there is some "quirk" in the
> product that is burning me. Something that you can't know about from
> reading the documentation.
> --
> Maz
>
> "Hilary Cotter" wrote:

Does full text indexing works on unicode field?

Hi all,
Does full text indexing supports searching on a unicode field, for
example, a field that stores chinese characters?
Thank you in advance.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
"alvinyyt" <alvinyyt@.gmail.com> wrote in message
news:1144720305.221875.221920@.e56g2000cwe.googlegroups.com...
> Hi all,
> Does full text indexing supports searching on a unicode field, for
> example, a field that stores chinese characters?
> Thank you in advance.
>|||Yes, make sure you select the appropriate language word breaker.
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
"alvinyyt" <alvinyyt@.gmail.com> wrote in message
news:1144720305.221875.221920@.e56g2000cwe.googlegroups.com...
> Hi all,
> Does full text indexing supports searching on a unicode field, for
> example, a field that stores chinese characters?
> Thank you in advance.
>

Documenting and searching a schema

Hi experts,
is there any external tool or feature within SQL Server 2005, which
enables a searchable documentation of schemas?
What I would like to do is to add descriptions to tables, columns and
foreign key relations describing their meaning in detail. By the term
"description" I do not mean a meaningful name, but (where required) a
longer, formatted text. Additional a google-like keyword search would
be nice, to be able to find matching elements, like e.g. all tables or
columns containing "customer" in the description text. The list of
search results should list the matching elements and show the first
few words of the description (very similar to the way google lists its
search results). If an element from the list is choosen, then the full
description should become visible. If the found elements could then be
dragged and dropped directly to a query builder - that would be
perfect!
As I don't think that I'm the first one thinking about enabling
documentation and search on database schemas, there should be tools
already existing for that purpose. But as I don't know any of them -
could you please suggest me some?
Kind regards,
Max
(send.me.all.email@.googlemail.com) writes:
> is there any external tool or feature within SQL Server 2005, which
> enables a searchable documentation of schemas?
> What I would like to do is to add descriptions to tables, columns and
> foreign key relations describing their meaning in detail. By the term
> "description" I do not mean a meaningful name, but (where required) a
> longer, formatted text. Additional a google-like keyword search would
> be nice, to be able to find matching elements, like e.g. all tables or
> columns containing "customer" in the description text. The list of
> search results should list the matching elements and show the first
> few words of the description (very similar to the way google lists its
> search results). If an element from the list is choosen, then the full
> description should become visible. If the found elements could then be
> dragged and dropped directly to a query builder - that would be
> perfect!
> As I don't think that I'm the first one thinking about enabling
> documentation and search on database schemas, there should be tools
> already existing for that purpose. But as I don't know any of them -
> could you please suggest me some?
You could look into SQLDoc from Red Gate (http://www.red-gate.com/). The
tool permits you to enter extended properties per table (not on column
level), and you can then generate a web site or HTML Help from the database.
Since HTML Help is searchable, this may be what you are looking for. You
can download a 14-day eval to have a look.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
|||Get a copy of Doc from ApexSQL (www.apexsql.com).
TheSQLGuru
President
Indicium Resources, Inc.
<send.me.all.email@.googlemail.com> wrote in message
news:1184095671.151380.170660@.o61g2000hsh.googlegr oups.com...
> Hi experts,
> is there any external tool or feature within SQL Server 2005, which
> enables a searchable documentation of schemas?
> What I would like to do is to add descriptions to tables, columns and
> foreign key relations describing their meaning in detail. By the term
> "description" I do not mean a meaningful name, but (where required) a
> longer, formatted text. Additional a google-like keyword search would
> be nice, to be able to find matching elements, like e.g. all tables or
> columns containing "customer" in the description text. The list of
> search results should list the matching elements and show the first
> few words of the description (very similar to the way google lists its
> search results). If an element from the list is choosen, then the full
> description should become visible. If the found elements could then be
> dragged and dropped directly to a query builder - that would be
> perfect!
> As I don't think that I'm the first one thinking about enabling
> documentation and search on database schemas, there should be tools
> already existing for that purpose. But as I don't know any of them -
> could you please suggest me some?
> Kind regards,
> Max
>

Documentation for RDL (Report Definition Language)

Hi,
I am searching for a document or the specification of RDL (Report Definition
Language). Does anyone know a good book or an online documentation dealing
with RDL?
Best regards,
ChristianReporting Services is still in beta so you aren't likely to
find any books out on the subject yet. You can sign up for
the beta to access some of the specifications in the help
file for the product:
http://www.microsoft.com/sql/reporting/default.asp
-Sue
On Mon, 10 Nov 2003 18:24:33 +0100, "Christian Nein"
<christian@.nein.de> wrote:
>Hi,
>I am searching for a document or the specification of RDL (Report Definition
>Language). Does anyone know a good book or an online documentation dealing
>with RDL?
>Best regards,
>Christian
>