full text indexing not starting automatically

Hello,
I've just started using full-text with SQL server 2000 (its version
8.00.760) . This is for a client, I'm a free-lancer.
I got it set up and running and am feeding in records. I want to have it
re-index every 5 minutes (I'm adding a batch of 100 new records or so every
5 minutes) These are news articles so i'm using an incremental update; the
old data will never change.
If I manually launch it by right-clicking the catalog icon and select "Start
Incremental Population" it works. I set up a schedule to run every 10
minutes but it doesn't automatically run. There doesn't appear to be any way
to mess that up; the dialog boxes for a scheduled item are crystal clear.
The 'enabled' checkbox is checked, the Job Type is 'Incremental
population', The 'Schedule frequency' is Recurring with the text:
Occurs every 1 day(s), every 10 minute(s) between 12:00:00 AM and 11:59:00
PM
What am I missing?
thanks,
John Mott
Use change tracking. Right click on the table a second time, select Change
Tracking. Then Right click again and select Update Index in Background
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
"John Mott" <johnmott59@.hotmail.com> wrote in message
news:e2ZqybvrFHA.4040@.TK2MSFTNGP14.phx.gbl...
> Hello,
> I've just started using full-text with SQL server 2000 (its version
> 8.00.760) . This is for a client, I'm a free-lancer.
> I got it set up and running and am feeding in records. I want to have it
> re-index every 5 minutes (I'm adding a batch of 100 new records or so
every
> 5 minutes) These are news articles so i'm using an incremental update; the
> old data will never change.
> If I manually launch it by right-clicking the catalog icon and select
"Start
> Incremental Population" it works. I set up a schedule to run every 10
> minutes but it doesn't automatically run. There doesn't appear to be any
way
> to mess that up; the dialog boxes for a scheduled item are crystal clear.
> The 'enabled' checkbox is checked, the Job Type is 'Incremental
> population', The 'Schedule frequency' is Recurring with the text:
> Occurs every 1 day(s), every 10 minute(s) between 12:00:00 AM and 11:59:00
> PM
> What am I missing?
> thanks,
> John Mott
>
|||Done, it looks like its churning. Thank you. I read about the types of
changes but I'm not clear on the difference between change tracking and
incremental update. Could you please explain the difference and why change
tracking is the appropriate choice for an application that only adds new
data?
Thank you for your response.
John Mott
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23KoriuvrFHA.3596@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> Use change tracking. Right click on the table a second time, select Change
> Tracking. Then Right click again and select Update Index in Background
> --
> 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
> "John Mott" <johnmott59@.hotmail.com> wrote in message
> news:e2ZqybvrFHA.4040@.TK2MSFTNGP14.phx.gbl...
> every
the[vbcol=seagreen]
> "Start
> way
clear.[vbcol=seagreen]
11:59:00
>
|||A full population extracts each row and indexes it.
An incremental population done on a table which does not have a timestamp
data type column on it will perform a full population under the covers.
An incremental population done on a table which does have a timestamp data
type column on it will result in each row being extracted and only the new
rows are reindexed. This full extraction has to be done so the indexer can
figure out which rows have been deleted, inserted, and modified. Note that
even on a row where the columns you are full text indexing have not been
modified (an integer column perhaps has been modified) the row will be
flagged for re-indexing.
Change tracking will initially require a full population (or an incremental
population if a full population has already being done). After this only
rows in which the columns you are full text indexing are modified will be
extracted and indexed.
By default this will only occur when you issue a sp_fulltext_table
'TableName','update_index', however with update index in background the
indexing process normally completes within seconds resulting in near real
time indexing.
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
"John Mott" <johnmott59@.hotmail.com> wrote in message
news:eZMjz4vrFHA.3988@.TK2MSFTNGP10.phx.gbl...[vbcol=seagreen]
> Done, it looks like its churning. Thank you. I read about the types of
> changes but I'm not clear on the difference between change tracking and
> incremental update. Could you please explain the difference and why change
> tracking is the appropriate choice for an application that only adds new
> data?
> Thank you for your response.
> John Mott
>
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%23KoriuvrFHA.3596@.TK2MSFTNGP15.phx.gbl...
Change[vbcol=seagreen]
it[vbcol=seagreen]
> the
any
> clear.
> 11:59:00
>
|||Wow. That is extremely illuminating. I intentionally put a timestamp column
and a small (4 byte) primary key field in the table to help the indexer, but
if its still checking each row on an incremental update that will get
expensive; this table will have millions of records.
Thank you very much for the explanation.
john
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:Owqz8BwrFHA.3604@.tk2msftngp13.phx.gbl...
> A full population extracts each row and indexes it.
> An incremental population done on a table which does not have a timestamp
> data type column on it will perform a full population under the covers.
> An incremental population done on a table which does have a timestamp data
> type column on it will result in each row being extracted and only the new
> rows are reindexed. This full extraction has to be done so the indexer can
> figure out which rows have been deleted, inserted, and modified. Note that
> even on a row where the columns you are full text indexing have not been
> modified (an integer column perhaps has been modified) the row will be
> flagged for re-indexing.
> Change tracking will initially require a full population (or an
incremental[vbcol=seagreen]
> population if a full population has already being done). After this only
> rows in which the columns you are full text indexing are modified will be
> extracted and indexed.
> By default this will only occur when you issue a sp_fulltext_table
> 'TableName','update_index', however with update index in background the
> indexing process normally completes within seconds resulting in near real
> time indexing.
> --
> 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
> "John Mott" <johnmott59@.hotmail.com> wrote in message
> news:eZMjz4vrFHA.3988@.TK2MSFTNGP10.phx.gbl...
change[vbcol=seagreen]
> Change
have[vbcol=seagreen]
> it
so[vbcol=seagreen]
update;[vbcol=seagreen]
select[vbcol=seagreen]
10
> any
>
|||the size of the pk is irrelevant in the indexing process (unless the pk is
huge or more than one col). A small pk does help with the regular (ie non
full-text) indexes.
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
"John Mott" <johnmott59@.hotmail.com> wrote in message
news:%23MgdHTwrFHA.2348@.tk2msftngp13.phx.gbl...
> Wow. That is extremely illuminating. I intentionally put a timestamp
> column
> and a small (4 byte) primary key field in the table to help the indexer,
> but
> if its still checking each row on an incremental update that will get
> expensive; this table will have millions of records.
> Thank you very much for the explanation.
> john
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:Owqz8BwrFHA.3604@.tk2msftngp13.phx.gbl...
> incremental
> change
> have
> so
> update;
> select
> 10
>

Full Catalog Update

Hi,
I ve found an issue about my seach engine text by using full-text catalogs.
So, my question is.. (maybe is stupid)
How to automatically update the catalog, when I update the tables ?
I ve seen there's a scheduler but does it mean, when I add some records into
the tables, the catalogue is not updated until the procedure starts ?
Stan>
> Hi,
> I ve found an issue about my seach engine text by using full-text
catalogs.
> So, my question is.. (maybe is stupid)
> How to automatically update the catalog, when I update the tables ?
> I ve seen there's a scheduler but does it mean, when I add some records
into
> the tables, the catalogue is not updated until the procedure starts ?
> Stan
--
Here is an extract from SQL Books online:
Maintaining Full-Text Indexes
There are three ways to maintain a full-text index:
Full rebuild
Rescans all rows. Completely rebuilds the full-text index. You can perform
a full rebuild immediately or on a schedule, using SQL Server Agent.
Timestamp-based incremental rebuild
Rescans those rows that have changed since the last full or incremental
rebuild. This requires a timestamp column on the table. Changes that do not
update the timestamp, such as WRITETEXT and UPDATETEXT, are not detected.
You can perform an incremental rebuild immediately or on a schedule.
Change tracking
Maintains a list of all changes to the indexed data. Changes made with
WRITETEXT and UPDATETEXT are not detected. You can update the full-text
index with these changes immediately, on a schedule, or as they occur,
using the background update index option.
The method you use depends on factors such as the CPU and available memory,
the amount and rate of change of data, the amount of available disk space,
and the importance of the full-text index being current. Use these
recommendations as a guide for selecting a maintenance method.
Use change tracking with the background update index option when CPU and
memory are available, the value of an up-to-date index is high, and
immediate propagation can keep up with the rate of changes.
Use change tracking with scheduled propagation when CPU and memory can be
used at scheduled times, disk space for storing changes is available, and
changes between the scheduled times are not so significant that the
propagation takes longer than a full rebuild.
Use a full rebuild when a large percentage of records change or are added
at once. If a large percentage of records change over an extended period of
time, consider using change tracking with scheduled or background update
index.
Use an incremental rebuild when a large number, but not a large percentage,
of documents change at one time. If a large number of records change over
an extended period of time, consider using change tracking with scheduled
or background update index.
Hope this helps,
--
Eric Cárdenas
support professional
This posting is provided "AS IS" with no warranties, and confers no rights.

Full Catalog Update

Hi,
I ve found an issue about my seach engine text by using full-text catalogs.
So, my question is.. (maybe is stupid)
How to automatically update the catalog, when I update the tables ?
I ve seen there's a scheduler but does it mean, when I add some records into
the tables, the catalogue is not updated until the procedure starts ?
Stan
>
> Hi,
> I ve found an issue about my seach engine text by using full-text
catalogs.
> So, my question is.. (maybe is stupid)
> How to automatically update the catalog, when I update the tables ?
> I ve seen there's a scheduler but does it mean, when I add some records
into
> the tables, the catalogue is not updated until the procedure starts ?
> Stan
Here is an extract from SQL Books online:
Maintaining Full-Text Indexes
There are three ways to maintain a full-text index:
Full rebuild
Rescans all rows. Completely rebuilds the full-text index. You can perform
a full rebuild immediately or on a schedule, using SQL Server Agent.
Timestamp-based incremental rebuild
Rescans those rows that have changed since the last full or incremental
rebuild. This requires a timestamp column on the table. Changes that do not
update the timestamp, such as WRITETEXT and UPDATETEXT, are not detected.
You can perform an incremental rebuild immediately or on a schedule.
Change tracking
Maintains a list of all changes to the indexed data. Changes made with
WRITETEXT and UPDATETEXT are not detected. You can update the full-text
index with these changes immediately, on a schedule, or as they occur,
using the background update index option.
The method you use depends on factors such as the CPU and available memory,
the amount and rate of change of data, the amount of available disk space,
and the importance of the full-text index being current. Use these
recommendations as a guide for selecting a maintenance method.
Use change tracking with the background update index option when CPU and
memory are available, the value of an up-to-date index is high, and
immediate propagation can keep up with the rate of changes.
Use change tracking with scheduled propagation when CPU and memory can be
used at scheduled times, disk space for storing changes is available, and
changes between the scheduled times are not so significant that the
propagation takes longer than a full rebuild.
Use a full rebuild when a large percentage of records change or are added
at once. If a large percentage of records change over an extended period of
time, consider using change tracking with scheduled or background update
index.
Use an incremental rebuild when a large number, but not a large percentage,
of documents change at one time. If a large number of records change over
an extended period of time, consider using change tracking with scheduled
or background update index.
Hope this helps,
Eric Crdenas
support professional
This posting is provided "AS IS" with no warranties, and confers no rights.