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

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

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

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

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

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

Строки длиной менее 60 символов работают нормально.

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

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

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

Нет никакой прокладки.

Ответ:

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

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


sql-server triggers
person Community    schedule 04.12.2008    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

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

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

person HTTP 410    schedule 04.12.2008

arrow_upward
2
arrow_downward

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

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

ИЗМЕНИТЬ:

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

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

person kristof    schedule 04.12.2008