FULLTEXT index and Change Tracking
michaeldye
Posts: 10 Bronze 2
Good morning,
Someone is bound to know the answer!
I compare two databases that I *think* are identical and get differing data on the FULLTEXT index bit:
Let side:
FULLTEXT INDEX ON [dbo].[IndexedView] KEY INDEX [MyPK] ON [MyFile]
Right side:
FULLTEXT INDEX ON [dbo].[IndexedView] KEY INDEX [MyPK] ON [MyFile] WITH CHANGE_TRACKING OFF
Yet I'm sure change tracking is on! And I go the full text index properties and it is.
What/why is SQLCompare producing a database schema with the change tracking off? (this is SQLSnapper that produces the schema for the right hand side - is that the issue???)
Thanks! Dr. Michael Dye.
Someone is bound to know the answer!
I compare two databases that I *think* are identical and get differing data on the FULLTEXT index bit:
Let side:
FULLTEXT INDEX ON [dbo].[IndexedView] KEY INDEX [MyPK] ON [MyFile]
Right side:
FULLTEXT INDEX ON [dbo].[IndexedView] KEY INDEX [MyPK] ON [MyFile] WITH CHANGE_TRACKING OFF
Yet I'm sure change tracking is on! And I go the full text index properties and it is.
What/why is SQLCompare producing a database schema with the change tracking off? (this is SQLSnapper that produces the schema for the right hand side - is that the issue???)
Thanks! Dr. Michael Dye.
Comments
My version of SQLSnapper was out of date. A quick Google to:
https://www.simple-talk.com/blogs/2014/ ... ql-snapper
And it tells you how to copy SqlSnapper from your SQLCompare directory. That seriously up-versioned my SQLSnapper and now the schemas match.
Well, except that the Assembly items are now appearing in the mis-match list; even though they don't???
Thanks, Dr. Michael Dye.