Строковые или двоичные данные будут усечены - проблема Гейзенберга

Question

Когда вы получаете эту ошибку, первое, что вы спрашиваете, какой столбец? К сожалению, SQL Server не помогает здесь. Таким образом, вы начинаете делать проб и ошибок. Ну, сейчас у меня есть такое утверждение:

INSERT tbl (A, B, C, D, E, F, G)
SELECT A, B * 2, C, D, E, q.F, G
  FROM tbl
      ,othertable q
 WHERE etc etc

Обратите внимание, что

• Некоторые значения изменены или связаны с другой таблицей, но большинство значений поступает из исходной таблицы, поэтому они не могут вызвать усечение, возвращаясь к тому же полю (о котором я знаю) .
• Удаление полей по одному в конечном итоге приводит к исчезновению ошибки, если я делаю это кумулятивно, , но - а вот кикер - не имеет значения, какие поля я исключаю, Как будто SQL Server возражает против общей длины строки, в чем я сомневаюсь, поскольку всего около 40 полей и ничего большого.

Кто-нибудь когда-либо видел это раньше?

Спасибо.

ОБНОВЛЕНИЕ: Я также провел "горизонтальное" тестирование, отфильтровав SELECT, с почти таким же результатом. Другими словами, если я скажу

• WHERE ID между 1 и 100: ошибка
• WHERE ID между 1 и 50: нет ошибки
• WHERE ID между 50 и 100: нет ошибки

Я перепробовал много комбинаций, и его нельзя ограничить одной строкой.

Answer 1

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

http://sqlqueryarchive.blogspot.com/2007/04/drop-all-statistics-2005.html

И вуаля , ВСТАВКА вернулась к нормальной работе. Почему статистика вызывает эту ошибку? Я не знаю, но это еще одна проблема ...

ОБНОВЛЕНИЕ: Эта ошибка возвращалась даже после удаления статистики. Поскольку я был убежден, что само сообщение было неточным (нет доказательств усечения), я выбрал это решение вместо:

SET ANSI_WARNINGS OFF
INSERT ...
SET ANSI_WARNINGS ON

Хорошо, это скорее взлом, чем решение, но оно позволяет мне - и, надеюсь, кому-то другому - перейти к другим вещам.

Answer 2

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

Ex. возможно, вы добавили столбец для отслеживания пользователя, который создал строку, например USER_ENTERED со значением по умолчанию suser_sname (), но длина столбца меньше текущего имени пользователя.

Answer 3

Существует ли причина, по которой вы не можете просто привести поля как структурный эквивалент их столбца назначения, например:

Select Cast(A as varchar(42))
, Cast(B * 2 as Decimal(18,4))
, Cast(C As varchar(10))
...
From Table

Недостатком этого подхода является то, что он усекает текстовые значения до предела их символов. Однако, если вы «уверены», что этого не произойдет, никакого вреда не будет.

Answer 4

Максимальный размер строки в SQL Server 2005 ограничен. См. здесь .

Большую часть времени вы столкнетесь с множеством столбцов nvarchar.

Answer 5

Да, когда я столкнулся с этим, мне пришлось создать другую таблицу / таблицы, которые имитируют текущую структуру. Затем я не изменил код, но изменил размеры моего типа данных на все nvarchar (MAX) для каждого поля, пока оно не остановилось, а затем удалил их по одному. Да, долго и затянуло, но у меня были серьезные проблемы, пытаясь что-нибудь еще. Как только я попробовал кучу вещей, которые вызывали слишком сильную головную боль, я просто решил использовать подход «пещерный человек», как мы смеялись над этим позже.

Также я видел похожую проблему с FKs, где вы должны спросить:

Каковы внешние ключевые ограничения? Есть ли?

Поскольку их нет, попробуйте компонент DataMgr этого парня:

http://www.bryantwebconsulting.com/blog/index.cfm/2005/11/21/truncated

Также проверьте это:

http://forums.databasejournal.com/showthread.php?t=41969

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=138456

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=97349

Вы также можете сбросить таблицу, из которой вы выбираете, во временную таблицу и узнать, какая строка выдает ошибку, если она выдает ошибку во временную таблицу.

В нем должна быть указана строка с ошибкой, если вы поместите каждый столбец в другую строку, в нем должно быть точно указано, где происходит бомбардировка.

Answer 6

Если это выглядит как "общая длина", то есть ли у вас триггер аудита, объединяющий столбцы для ведения журнала?

Редактировать: после вашего обновления я действительно учел бы тот факт, что у вас есть триггер, вызывающий это ...

Изменить 2, увидев ваш статистический ответ ...

Поскольку общая длина атрибута статистики, вероятно, была больше, чем 900 байт ? Не уверен, относится ли это к статистике, и я не уверен.

У вас есть ссылка, пожалуйста, потому что я хотел бы знать, почему статистика будет обрезаться, когда они являются просто двоичными гистограммами (IIRC)