Full Text Search - Auto Change Tracking

Id like to know a bit about the behaviour of CHANGE_TRACKING AUTO, specifically when the update of the index takes place. In the docs it states 'these changes may not be reflected immediately' but in general when can the changes be expected to appear. Is there merit to updating manually, although the user needs ALTER permission on the table in that case vs. letting SQL Server run it automatically.

Thanks for any help - MikeIn case you or anyone else has found any relevant information about this topic I'd also be interested to hear about it since the documentation doesn't really clear things up.

kind regards,
heinz

Full Text Search - Auto Change Tracking

Id like to know a bit about the behaviour of CHANGE_TRACKING AUTO, specifically when the update of the index takes place. In the docs it states 'these changes may not be reflected immediately' but in general when can the changes be expected to appear. Is there merit to updating manually, although the user needs ALTER permission on the table in that case vs. letting SQL Server run it automatically.

Thanks for any help - Mike
In case you or anyone else has found any relevant information about this topic I'd also be interested to hear about it since the documentation doesn't really clear things up.

kind regards,
heinz

Full text index not tracking changes on an indexed view

We had a peculiar situation today where our lovely indexed view
obviously had textual data in it but some recently added rows were not
being returned in a CONTAINS query when they should have been.
Deleting and recreating the FT index fixed things immediately and I
can't seem to reproduce it but it worries me for our live deployment
(due imminently!).
Has anyone else seen this? Is it reproducible (and fixable?!)
Mark
Hi Mark,
Do you have a timestamp column in underlaying table(s) ?
Have you activated automatic change tracking for your index ?
Jean-Pierre Riehl
http://blog.djeepy1.net
http://www.bewise.fr
<mbedser@.gmail.com> wrote in message
news:1185555299.154393.224920@.d55g2000hsg.googlegr oups.com...
> We had a peculiar situation today where our lovely indexed view
> obviously had textual data in it but some recently added rows were not
> being returned in a CONTAINS query when they should have been.
> Deleting and recreating the FT index fixed things immediately and I
> can't seem to reproduce it but it worries me for our live deployment
> (due imminently!).
> Has anyone else seen this? Is it reproducible (and fixable?!)
> Mark
>
|||Change tracking does not require a timestamp column.
I think your problem will be solved if you do use change tracking (as the
previous poster points out).
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
"Jean-Pierre Riehl" <jean-pierre.riehl@.b-e-w-i-s-e.fr> wrote in message
news:1C0C02A3-0A2F-4294-97CA-59E453DE6780@.microsoft.com...
> Hi Mark,
> Do you have a timestamp column in underlaying table(s) ?
> Have you activated automatic change tracking for your index ?
> --
> Jean-Pierre Riehl
> http://blog.djeepy1.net
> http://www.bewise.fr
> <mbedser@.gmail.com> wrote in message
> news:1185555299.154393.224920@.d55g2000hsg.googlegr oups.com...
>
|||I apologize for my mistake. Incremental update requires a timestamp column
whereas change tracking doesn't.
Jean-Pierre Riehl
http://blog.djeepy1.net
http://www.bewise.fr
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23CQlfIT0HHA.1188@.TK2MSFTNGP04.phx.gbl...
> Change tracking does not require a timestamp column.
> I think your problem will be solved if you do use change tracking (as the
> previous poster points out).
> --
> 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
> "Jean-Pierre Riehl" <jean-pierre.riehl@.b-e-w-i-s-e.fr> wrote in message
> news:1C0C02A3-0A2F-4294-97CA-59E453DE6780@.microsoft.com...
>