Это, кажется, еще одно из многих ограничений фильтруемых индексов. Попытка обойти это с LIKE
помощью WHERE column01 LIKE '_____'
тоже не работает, выдает то же сообщение об ошибке ( «Неверное предложение WHERE ...» ).
Помимо VIEW
решения, другим способом было бы преобразовать вычисляемый столбец в обычный столбец и добавить CHECK
ограничение, чтобы оно всегда имело правильные данные:
CREATE TABLE Table01 (column01 nvarchar(100),
column01_length int,
CHECK ( column01_length = len(column01)
AND column01 IS NOT NULL
AND column01_length IS NOT NULL
OR column01 IS NULL
AND column01_length IS NULL )
) ;
CREATE UNIQUE INDEX UIX_01 ON Table01 (column01) WHERE column01_length >= 5 ;
Проверено на rextester.com
Естественно, это означает, что вам нужно явно указывать column01_length
правильную длину при каждом заполнении column01
(при вставках и обновлениях). Это может быть сложно, потому что вам нужно убедиться, что длина рассчитывается так же, как это LEN()
делает функция T-SQL . В частности, необходимо игнорировать конечные пробелы, что не обязательно означает, как длина вычисляется по умолчанию в различных языках программирования, на которых написаны клиентские приложения. Логика может быть проста для учета в вызывающей программе, но вам необходимо осознавая разницу в первую очередь.
Опцией может быть INSERT/UPDATE
триггер 1, чтобы указать правильное значение для столбца, поэтому оно выглядит так, как оно рассчитывается для клиентских приложений.
1 Как объясняется в разделе «Триггеры по сравнению с ограничениями» , для этого вам потребуется использовать триггер INSTEAD OF. Триггер AFTER просто никогда не будет выполнен, потому что отсутствующая длина не выполнит проверочное ограничение, а это, в свою очередь, помешает запуску триггера. Триггеры INSTEAD OF, однако, имеют свои собственные ограничения ( краткий обзор см. В Руководстве по планированию триггеров DML ).