Проблема MS SQL - длина поля ограничена

Question

У меня есть БД MS SQL с различными таблицами, и одно поле, в частности, вызывает у меня горе.

Тип данных установлен на varchar (100), однако поле может содержать не более 60 символов.

Если я пытаюсь вставить в поле любую строку, содержащую более 60 символов, я получаю исключение, "Строка или двоичные данные будут проигнорированы". Хотя строка короче явно заданного типа данных, она все равно выдает исключение.

Возможно, есть настройка БД, которая делает это? Что может вызвать перезапись явно установленного типа данных?

Редактировать:
Триггеры не копируют значение и не вставляют его в другую таблицу, а также не используют данные. - (Неверно)

Строки, которые меньше 60 символов, работают нормально.

Все столбцы, имеющие varchar (100), создают ту же проблему, но все остальные столбцы принимают правильные значения. Колонка varchar (10) работает нормально.

Любая строка в этой таблице вызывает исключение, если я пытаюсь обновить поле строкой длиной более 60 символов.

Я пытаюсь вставить данные непосредственно в поле с помощью SQL Server Management Studio.

Заполнение не включено.

Ответ:

Была вторая таблица, в которой для столбца было задано значение 60. Триггер обновления назывался хранимой процедурой, которая вставляет данные в таблицу «денормализованных».

Спасибо за помощь.

Answer 1

Возможно, вам нужен NVARCHAR (100) или, скорее, NVARCHAR (60).

Один символ в NVARCHAR в два раза больше VARCHAR. Вы бы использовали NVARCHAR, если ваши входные данные в Unicode

EDIT:

Исходя из ваших комментариев, похоже, что использование nvarchar не является необходимым решением проблемы, и довольно сложно догадаться, в чем проблемы с предоставленной информацией:

Не могли бы вы написать скрипт для своей таблицы с ограничениями и триггерами и опубликовать код, который определенно поможет найти источник проблемы.

Answer 2

Что говорит функция метаданных COL_LENGTH, это определенный размер этого столбца?

Есть ли у вас ограничение длины по умолчанию для этого столбца?

Исходя из предыдущих ответов, что это не проблема триггера или проблема nvarchar, и вы думаете, что усечение имеет длину 60, что делает обновление этого единственного столбца с SUBSTRING длины 60, а затем 61? Это может подтвердить или опровергнуть вашу теорию.

В качестве альтернативы возможно, что параметры сортировки и / или кодировки базы данных изменились с момента вставки исходных данных. Это может привести к некоторым особенностям. Вы говорите, что это копия исходной базы данных. Он сидит на другом экземпляре SQL Server? Если да, оба экземпляра SQL Server имеют одинаковые параметры сортировки и кодировки?

EDIT : использование обсуждаемого параметра ANSI_PADDING устарело, и оно будет постоянно включено в будущих версиях SQL Server. Но тот факт, что вы смотрите на это, говорит о том, что значение, которое вы пытаетесь вставить, дополняется каким-то образом, возможно, конечными пробелами. Однако это не согласуется с результатами вашего эксперимента SUBSTRING, который показывает обрезание в 60 символов. Поэтому я не уверен, имеет ли значение этот параметр, особенно потому, что он всегда включен для столбца nvarchar.

Любая строка из 61 символа вызывает исключение обновления? Кроме того, хотя вы проверили триггеры непосредственных таблиц, существуют ли какие-либо каскадные (косвенные) триггеры, которые могут вызывать это исключение?