Full-text indexes

Brian Donahue

Hi Francois,

Can you tell us what the migration is attempting to do? For instance are
you changing a table from having a primary key to not having one? Does the
table need to be rebuilt?

Maybe we could figure out the problem if you sent us SQL scripts of both
tables (with full-text information) and let us know which direction you were
migrating in. That might allow us to reproduce the problem.

Regards,

Brian Donahue
Red Gate Technical Support


"Francois" <flachance@businesswatch.ca> wrote in message
news:esD2qUbdEHA.1508@server53...
> I seem to be getting the following error whenever SQL Compare has
scripted
> a change to a table which is using Full-Text indexing:
>
> Cannot drop index 'PK_CustAddress' because it enforces the full-text key
for
> table 'CustAddress'.
>
> Shouldn't that kind of stuff be handled in the synchronization script? I
> end up manually removing full-text indexing from the tables involved and
> re-run the synchronization script. I'm running SQL Compare 3.1.7.
>
> Thanks!
>
>

Brian Donahue

I think this may be happening due to the full-text index information being changed at the end of the script that SQL Compare makes. Because changing full-text catalogs can't be done inside a transaction, our only recourse is to change the full-text catalogs at the end after the transactional part of the script has run.

Since SQL 2005 now supports this, however, we are looking into changing SQL Compare to get this working.