Проблема
Предположим, что первичный ключ в столбце, который включает в себя большие десятичные или числовые значения, в Microsoft SQL Server 2012, 2014 или 2016 создается первичный ключ. Затем нужно создать полнотекстовый индекс, используя этот столбец в качестве уникального ключевого индекса. В этом случае, если есть строки, которые не удалось проиндексировать, полнотекстовое значение ключа будет записано как отрицательное число или символы Юникода. Поэтому невозможно определить строки, которые не удалось проиндексировать.
Решение
Эта проблема устранена в следующих накопительных обновлениях для SQL Server:
Накопительный пакет обновления 2 для SQL Server 2016 с пакетом обновления 1 (SP1)
Накопительный пакет обновления 4 для SQL Server 2016
Накопительный пакет обновления 6 для SQL Server 2012 с пакетом обновления 3 (SP3)
Накопительный пакет обновления 10 для SQL Server 2014 SP1
Накопительный пакет обновления 3 для SQL Server 2014 SP2
Сведения о накопительных обновлениях для SQL Server
Каждый новый накопительный пакет обновления для SQL Server содержит все исправления и исправления безопасности, которые входили в состав предыдущего накопительного пакета обновления. Ознакомьтесь с последними накопительными пакетами обновления для SQL Server:
Последний накопительный пакет обновления для SQL Server 2016
Последний накопительный пакет обновления для SQL Server 2012
Временное решение
Чтобы обойти эту проблему, добавьте в таблицу уникальный столбец bigint или int и укажите полный текст с помощью этого столбца. Функции Int и bigint правильно сообщают свои значения в полнотекстовый журнал ошибок, когда сообщается о неправильной строке или документе. Уникальный столбец, используемый в полнотекстовом формате, не обязательно должен быть первичным ключом таблицы.
Состояние
Корпорация Майкрософт подтвердила, что это проблема продуктов Microsoft, перечисленных в разделе «Относится к».
Ссылки
Узнайте о терминологии, используемой корпорацией Майкрософт для описания обновлений программного обеспечения.