Строковые или двоичные данные будут усечены-задача Гейзенберга
когда вы получаете эту ошибку, первое, что вы спрашиваете, какой столбец? К сожалению, 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 полей и ничего большого.
кто-нибудь видел этого раньше?
спасибо.
обновление: I также сделали "горизонтальное" тестирование, отфильтровав SELECT, с почти тем же результатом. Другими словами, если я скажу
- где id между 1 и 100: ошибка
- где id между 1 и 50: нет ошибки
- где id между 50 и 100: нет ошибки
Я пробовал много комбинаций, и это не может быть ограничено одной строкой.
6 ответов
хотя таблица не имела ключей, ограничений, индексов или триггеров, она сделал есть статистика, и в этом заключается проблема. Я убил всю статистику таблицы, используя этот скрипт
http://sqlqueryarchive.blogspot.com/2007/04/drop-all-statistics-2005.html
и вуаля!, вставка вернулась к нормальной работе. Почему статистика вызывает эту ошибку? Я не знаю, но это другое проблема...
обновление: эта ошибка вернулась даже с удаленной статистикой. Поскольку я был убежден, что само сообщение было неточным (нет никаких доказательств усечения), я пошел с данное решение вместо:
SET ANSI_WARNINGS OFF
INSERT ...
SET ANSI_WARNINGS ON
хорошо, это скорее взлом, чем решение, но это позволяет мне - и, надеюсь, кому - то еще-перейти к другим вещам.
есть ли причина, по которой вы не можете просто привести поля в качестве структурного эквивалента их целевого столбца, например:
Select Cast(A as varchar(42))
, Cast(B * 2 as Decimal(18,4))
, Cast(C As varchar(10))
...
From Table
недостатком этого подхода является то, что он будет усекать текстовые значения на их пределе символов. Однако, если вы "уверены", что этого не должно произойти, тогда никакого вреда не будет.
в некоторых случаях вы можете столкнуться с проблемой, если у вас есть какой-либо другой столбец со значениями по умолчанию, которые могут вызвать проблему.
Ex. возможно, вы добавили столбец для отслеживания пользователя, создавшего строку, например USER_ENTERED со значением по умолчанию suser_sname (), но длина столбца меньше текущего имени пользователя.
в SQL Server 2005 существует ограничение максимального размера строки. См.здесь.
большую часть времени вы столкнетесь с этим w/lots столбцов nvarchar.
Да, когда я столкнулся с этим, мне пришлось создать другую таблицу/таблицы, которые имитируют текущую структуру. Затем я не изменил код, но изменил размеры типов данных на все nvarchar (MAX) для каждого поля, пока он не остановился, а затем устранил их один за другим. Да, долго и затянулся, но у меня были серьезные проблемы, пытаясь что-то еще. Однажды я попробовал кучу вещей, которые вызывали слишком большую головную боль, я просто решил использовать подход "пещерного человека", как мы смеялись об этом позже.
также Я видел аналогичную проблему с FKs, где вы должны спросить:
каковы ключевые ограничения foriegn? А они есть?
поскольку их нет, попробуйте компонент DataMgr этого парня:
http://www.bryantwebconsulting.com/blog/index.cfm/2005/11/21/truncated
также проверьте это out:
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
вы также можете сбросить таблицу, которую вы выбираете, в временную таблицу и узнать, какая строка дает ошибку, если она ошибается в временную таблицу.
Он должен сообщить вам строку в ошибке, если вы поместите каждую колонку на другую линию, она должна точно сказать вам, где она бомбит.
Если это выглядит как "общая длина", то у вас есть триггер аудита, объединяющий столбцы для ведения журнала?
Edit: после вашего обновления я бы действительно рассмотрел тот факт, что у вас есть триггер, вызывающий это...
Edit 2, после просмотра вашего ответа статистики...
потому что общая длина атрибута статистики была, вероятно, больше, чем 900 байт? Не уверен, что это относится к статистике, хотя и я не убежден.
У вас есть ссылка пожалуйста, потому что я хотел бы знать, почему статистика будет усекать, когда они просто бинарные гистограммы (IIRC)