Full Text Search for Stand Alone Windows App

I am working on a stand-alone windows application in which I need to provide full text search capability. I was using SQL Express edition and was planning to deploy the database (.mdf) with the application.

Is it possible to enable Full Text search for a database which does not belong to a database server (embedded with the app)? If yes the how can you do it?

If its not possible then what are the alternatives/options of data-storage for a windows app which will allow me to enable Full Text search?

Thanks for your help.

To enable full text search your sever must be installed with this capability.

To enable this capability in the sql server 2005 express edition, you have to download the sql server 2005 express edition advanced. This will install the database server, the sql managment studio and the full text serch.

|||

Thanks for your reply. However I already have the "advanced services" installed but my full text button is still disabled in VS Server Explorer.

If I add the database on a named instance for instance MyBox\SQLExpress then i get an option of enabling the Full Text Search but I dont see any option for a stand-alone database file.

|||

Hi,

I would like to introduce some good video learning resources to you which demonstrates how to set up Full-Text within SQL Server Express.These resources demonstrate how to set up Full-Text search paying particular attention to the nuances of setting it up within SQL Server Express.

http://msdn.microsoft.com/vstudio/express/sql/learning/default.aspx#13

Hope that helps. Thanks.

|||

Thanks a lot for your reply. I found out that full text is not available for "user instances" that is why I am not able to get it to work.

I think I may just have to go with SQL Lite. Does any one know any other database solution which might be better then this? Thanks.

Full Text Index Issue

Hey all,
I'm using full text indexing for keyword search capabilities for one of our
clients'. We needed to provide boolean search capability and hence I chose
containstable instead of freetext.
The stored proc works fine except that for specific keywords the client
expects certain documents to show which do not. This is really random and we
have not been able to find out why these documents don't show inspite of the
keyword being the the document name and summary. We also made sure the
document exists in the indexed table.
We did not want to re-populate the catalog because when we did it in the
past the client was able to find 5 documents and 10 others were not showing
up.
We even tried defragmenting the drive SQL server sits on, which did not
help. Has anyone experienced this before?
Any help will be greatly appreciated.
-Aarti.
a defrag won't help. Are there any messages in the event log from MSSCI or
MSSearch?
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
"Aarti." <Aarti@.discussions.microsoft.com> wrote in message
news:73F8C6ED-2ACE-438E-B341-9DEE30D122AC@.microsoft.com...
> Hey all,
> I'm using full text indexing for keyword search capabilities for one of
our
> clients'. We needed to provide boolean search capability and hence I chose
> containstable instead of freetext.
> The stored proc works fine except that for specific keywords the client
> expects certain documents to show which do not. This is really random and
we
> have not been able to find out why these documents don't show inspite of
the
> keyword being the the document name and summary. We also made sure the
> document exists in the indexed table.
> We did not want to re-populate the catalog because when we did it in the
> past the client was able to find 5 documents and 10 others were not
showing
> up.
> We even tried defragmenting the drive SQL server sits on, which did not
> help. Has anyone experienced this before?
> Any help will be greatly appreciated.
> -Aarti.
|||Thanks for your response.
I deleted and recreated the FT catalog. Here's the list of messages in the
event log:
MS Search Gatherer : The end of crawl for project <SQLServer SQL0000600005>
has been detected. The Gatherer successfully processed 10373 documents
totaling 0K. It failed to filter 2936 documents. 0 URLs could not be reached
or were denied access.
SQLFTHNDLR: One or more documents stored in image columns with extension
'doc' did not get full-text indexed because loading the filter failed with
error '0x1'.
Note: These documents will not be passed to MSSearch for indexing, and
therefore this failure will not be reflected in the end of crawl summary
statistics.
SQLFTHNDLR: One or more documents stored in image columns with extension
'vb' did not get full-text indexed because loading the filter failed with
error '0x1'.
Note: These documents will not be passed to MSSearch for indexing, and
therefore this failure will not be reflected in the end of crawl summary
statistics.
SQLFTHNDLR: One or more documents stored in image columns with extension
'wpd' did not get full-text indexed because loading the filter failed with
error '0x1'.
Note: These documents will not be passed to MSSearch for indexing, and
therefore this failure will not be reflected in the end of crawl summary
statistics.
MS Search Gatherer : One or more warnings or errors for Gatherer project
<SQLServer SQL0000600005> were logged to file <d:\Microsoft SQL
Server\MSSQL\FTData\SQLServer\GatherLogs\SQL000060 0005.1.gthr>. If you are
interested in these messages, please, look at the file using the gatherer log
query object (gthrlog.vbs, log viewer web page).
Please let me know if you need any more information.
Thanks in advance.
"Hilary Cotter" wrote:

> a defrag won't help. Are there any messages in the event log from MSSCI or
> MSSearch?
> --
> 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
> "Aarti." <Aarti@.discussions.microsoft.com> wrote in message
> news:73F8C6ED-2ACE-438E-B341-9DEE30D122AC@.microsoft.com...
> our
> we
> the
> showing
>
>