FullText Schedules

On the fulltext indexing Schedules Properties within
Enterprise Manager for a full-text table ... listed
is "full population", "incremental population",
and "update index". Please clarify the "update index"
option and how this differs from full or incremental. I
have a clear understanding of full and incremental... but
the Help information does not clarify "update index".
Thanks
PhilipPhilip,
"Update index" is doc'ed in the BOL as "Update Index in Background", see BOL
for "Change Tracking" vs. Incremental for the differences. FYI, you should
post these in the fulltext newsgroup!
Regards,
John
"Philip" <plippard@.nc.rr.com> wrote in message
news:01c601c34f23$aaf3a610$a501280a@.phx.gbl...
> On the fulltext indexing Schedules Properties within
> Enterprise Manager for a full-text table ... listed
> is "full population", "incremental population",
> and "update index". Please clarify the "update index"
> option and how this differs from full or incremental. I
> have a clear understanding of full and incremental... but
> the Help information does not clarify "update index".
> Thanks
> Philip

Full-text population very slow

Hello, I have a vague question. I have a table with two full-text indexed
columns and 500 000 rows. Previously when only one of the columns was
full-text indexed, the full population took only minutes. Now that there are
two columns, it seems to never finish, or at least is very slow. I have
searched for solution but found nothing, except that perhaps the November CTP
version of SQL 2005 could fix this problem. Does that version fix any known
bugs?
Any help much appreciated...
Thanks, Harri
It is strange. My table is:
CREATE TABLE [dbo].[Search](
[Customer] [varchar](20) NOT NULL,
[Modified] [datetime] NOT NULL DEFAULT ('1900-01-01 00:00:00.000'),
[RowVer] [timestamp] NOT NULL,
[Search] [nvarchar](3999) NOT NULL DEFAULT (''),
[Search2] [ntext] NULL,
CONSTRAINT [PK_Search] PRIMARY KEY CLUSTERED ([Customer] ASC)
)
If I full-text index only Search column, it succeeds in 4 minutes. If I
full-text index only Search2 column, and if all the values in that column are
NULL (but there are over 500 000 rows), then population never finishes.
CREATE FULLTEXT INDEX ON dbo.Search(Search2 LANGUAGE 0) KEY INDEX PK_Search
ON CPMCatalog WITH CHANGE_TRACKING MANUAL
|||Okay, problem solved. It is just the "ntext" data type, it is awfully slow
(same with nvarchar(max)). I guess that I have to create another table, and
remove Search2 column.
|||TEST2
"Harri Pesonen" <HarriPesonen@.discussions.microsoft.com> wrote in message
news:E7A12825-3326-488E-8F47-3F664A6A959E@.microsoft.com...
> Currently I am suspecting that the problem happens because most of the
> rows
> contain same words (this is testing material only). I will next try to
> randomize the words.
|||testyaser
"Harri Pesonen" <HarriPesonen@.discussions.microsoft.com> wrote in message
news:3E84A976-E2DD-4A99-818E-6C923D069E74@.microsoft.com...
> Hello, I have a vague question. I have a table with two full-text indexed
> columns and 500 000 rows. Previously when only one of the columns was
> full-text indexed, the full population took only minutes. Now that there
> are
> two columns, it seems to never finish, or at least is very slow. I have
> searched for solution but found nothing, except that perhaps the November
> CTP
> version of SQL 2005 could fix this problem. Does that version fix any
> known
> bugs?
> Any help much appreciated...
> Thanks, Harri

Full-Text population problems

Hi

I'm getting the following error when I attempt to populate our Full Text Index on SQL
2000: The crawl seed in project SQL0000500005> cannot be accessed. Error: 800705b4 - This operation returned because
the timeout period expired. .

The crawl for project could not be started,
because no crawl seeds could be accessed. Fix the errors and try the crawl again.

I have seen in other threads and on the MS site how this is caused by the MSSQLService and the MS Search services not being syncronized and it can be fixed by changing the MSSQLService account to use the system account and back again.

The BUILTIN\Administrators group is present in SQL and has OWNER permissions. I even tried giving the SYSTEM group full access to the FTDATA folder.

This did NOT work for me. I am still getting the messages. One thing that is probably unique to my instalation is that it resides on the only server on this network so it is also the primary domain controler. Could this be why I cannot get the FT population to work?

I have another machine on a seperate network that is not a PDC and FT-Indexing works great on it but that doesn't help me for the network I need it to work on.

Does anyone have any other ideas I could try? I have been working on this for close to a week now.

The "Mav"How about the SQL Services account privileges and which accout is used?

Check what is the current state of process for indexing.

Refer to this
KBA (http://support.microsoft.com/default.aspx?scid=KB;en-us;q317746) to resovle the issue.|||I looked through that document and I have tried all that still no dice. The MS Search service is using the Local System account and the MSSQLServer service is using the local server administrator account. I tried changing this to the Local System acount using SQL Server Enterprise Manager(SSEM) this did not work so I changed it back to the local administrator account, once again using the SSEM.

Any other suggestions?

Thanks,
The Mav|||No one has any ideas? =(

full-text population problem

I have a problem in full population for a full text index.
When I run the population; these are the results
- Population duration : 3-5 seconds.
- item count : 0
- catalog size : 0
- unique key count : 1
although I have 7 million of records in that table
I need explanation please.
Than you
************************************************** ********************
Sent via Fuzzy Software @. http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...
can you look in the application log for event messages from MSSearch or
MSSCI?
Most often this problem is caused by
1) changing the SQL Server service account through control panel instead of
Enterprise Manager
2) changing MSSearch's service account to a local or domain account instead
of keeping in local system
3) removing the builtin\administrators group from the system administrators
role.
to fix 1 refer to
http://support.microsoft.com/default...b;en-us;277549
to fix 2 click Start, point to settings, click control panel, double click
administrative tools, double click on services, double click Microsoft
Search, click the Logon tab, and select Local System, clear the Allow the
service to interact with the desktop, click on Apply and ok, and accept all
defaults
to fix 3 execute the below tsql in Query Analyzer
--Grant [NT Authority\System] a logon to SQL Server:
EXEC sp_grantlogin [NT Authority\System]
--Add that account to the sysadmins role:
EXEC sp_addsrvrolemember @.loginame = [NT Authority\System] , @.rolename =
'sysadmin'
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Mohamed Salah" <msalah_din@.yahoo.com> wrote in message
news:u5Ls8eicEHA.3944@.tk2msftngp13.phx.gbl...
> I have a problem in full population for a full text index.
> When I run the population; these are the results
> - Population duration : 3-5 seconds.
> - item count : 0
> - catalog size : 0
> - unique key count : 1
> although I have 7 million of records in that table
> I need explanation please.
> Than you
> ************************************************** ********************
> Sent via Fuzzy Software @. http://www.fuzzysoftware.com/
> Comprehensive, categorised, searchable collection of links to ASP &
ASP.NET resources...
|||You did build the catalogue first and then try a full-text population?

Full-Text Population Fails for Specific Table

I have a SQL Server 2000 database with the latest service pack (3?). For some time, I've had full-text indexing working. Eventually, one of my full-text catalogs failed to populate. After a rebuild, I still couldn't populate it. I dropped it and recreated several catalogs. Eventually, I was able to get all of the original tables into a full-text catalog that populates except one. The offending table has less than 4000 rows in it. It is now in its own catalog which refuses to populate. I can't find any errors in the Application Log that correspond to this catalog population failing.

I expect that since the catalog used to populate, but will no longer populate, this must have something to do with the data added to the table recently.

Do these symptoms match any known issues? What should I do to debug this issue? I'm stuck.

Please help. Thank you.

Dave McCall? Do the gatherer logs reveal anything? -- Hilary CotterDirector of Text Mining and Database StrategyRelevantNOISE.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 FTShttp://www.indexserverfaq.com <Dave McCall@.discussions.microsoft.com> wrote in message news:b6cf47d2-6c0a-4c82-a9f9-42f1d2b71454@.discussions.microsoft.com...I have a SQL Server 2000 database with the latest service pack (3?). For some time, I've had full-text indexing working. Eventually, one of my full-text catalogs failed to populate. After a rebuild, I still couldn't populate it. I dropped it and recreated several catalogs. Eventually, I was able to get all of the original tables into a full-text catalog that populates except one. The offending table has less than 4000 rows in it. It is now in its own catalog which refuses to populate. I can't find any errors in the Application Log that correspond to this catalog population failing.I expect that since the catalog used to populate, but will no longer populate, this must have something to do with the data added to the table recently.Do these symptoms match any known issues? What should I do to debug this issue? I'm stuck.Please help. Thank you.Dave McCall