Строка или двоичные данные были бы усеченными — Heisenberg проблема
Когда Вы получаете эту ошибку, первая вещь, которую Вы спрашиваете, который столбец? К сожалению, 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 полей всего и ничто большое.
Кто-либо когда-нибудь замеченный это прежде?
Спасибо.
ОБНОВЛЕНИЕ: Я также сделал "горизонтальное" тестирование, путем отфильтровывания ВЫБОРА, с почти таким же результатом. Другими словами, если я говорю
- ГДЕ идентификатор МЕЖДУ 1 И 100: Ошибка
- ГДЕ идентификатор МЕЖДУ 1 И 50: Никакая ошибка
- ГДЕ идентификатор МЕЖДУ 50 И 100: Никакая ошибка
Я попробовал много комбинаций, и это не может быть ограничено одной строкой.
5 ответов
Хотя таблица не имела ключей, ограничений, индексов или триггеров, она имела статистику, и в этом заключалась проблема. Я убил всю статистику таблицы с помощью этого скрипта
http://sqlqueryarchive.blogspot.com/2007/04/drop-all-statistics-2005.html
И вуаля , INSERT был вернуться к нормальной работе. Почему статистика вызывает эту ошибку? Не знаю, но это еще одна проблема ...
ОБНОВЛЕНИЕ: Эта ошибка вернулась даже после удаления статистики. Поскольку я был убежден, что само сообщение было неточным (нет доказательств усечения), я выбрал это решение вместо этого:
SET ANSI_WARNINGS OFF
INSERT ...
SET ANSI_WARNINGS ON
Хорошо, это больше похоже на взлом, чем на решение, но оно позволяет мне - и, надеюсь, кто-то другой - чтобы перейти к другим вещам.
Да, когда я столкнулся с этим, мне пришлось создать другую таблицу / таблицы, имитирующие текущую структуру. Затем я не менял код, но изменил размеры моих типов данных на все nvarchar (MAX) для каждого поля, пока оно не остановилось, а затем удалил их один за другим. Да, долго и растянуто, но у меня были серьезные проблемы с попытками что-то еще. После того, как я попробовал кучу вещей, которые вызывали слишком сильную головную боль, я просто решил применить подход «пещерного человека», поскольку мы смеялись над этим позже.
Также я видел аналогичную проблему с FK, где вы должны спросить:
Каковы ограничения внешних ключей? Есть ли какие-нибудь?
Поскольку их нет, попробуйте компонент 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
Вы также можете сбросить таблицу, которую вы выбираете, во временную таблицу и узнать, какая строка выдает ошибку, если она выдает ошибку, во временную таблицу .
Он должен сообщить вам строку в ошибке, если вы поместите каждый столбец в другую строку, он должен сказать вам, где именно происходит бомбардировка.
Если это выглядит как «общая длина», то есть ли у вас триггер аудита, объединяющий столбцы для ведения журнала?
Изменить: после вашего обновления я бы действительно стал примите во внимание тот факт, что у вас есть триггер, вызывающий это ...
Отредактируйте 2, увидев ваш ответ статистики ...
Поскольку общая длина атрибута статистики, вероятно, была больше, чем 900 байт ? {{ 1}} Не уверен, что это относится к статистике, и я не уверен.
У вас есть ссылка, потому что я хотел бы знать, почему статистика обрезается, если это просто двоичные гистограммы (IIRC)
Есть ли причина, по которой вы не можете просто преобразовать поля как структурный эквивалент их целевого столбца, например:
Select Cast(A as varchar(42))
, Cast(B * 2 as Decimal(18,4))
, Cast(C As varchar(10))
...
From Table
Обратной стороной этого подхода является что он будет усекать текстовые значения до предела символов. Однако если вы «уверены», что этого не должно произойти, то вреда не будет.
В SQL Server 2005 существует ограничение на максимальный размер строки. См. здесь.
Большую часть времени вы столкнетесь с этим множеством столбцов nvarchar.