Я участвую в проекте по миграции данных. Я получаю следующую ошибку при попытке вставить данные из одной таблицы в другую таблицу (SQL Server 2005):
Сообщение 8152, уровень 16, состояние 13, строка 1
Строка или двоичные данные будут обрезаны.
Столбцы исходных данных соответствуют типу данных и находятся в пределах определений длины столбцов таблицы назначения, поэтому я не понимаю, что может быть причиной этой ошибки.
sql-server
tsql
sql-server-2005
migration
data-migration
Джим Эванс
источник
источник
Ответы:
Вам нужно будет опубликовать определения таблиц для исходной и целевой таблиц, чтобы мы могли выяснить, где проблема, но суть в том, что один из ваших столбцов в исходной таблице больше, чем столбцы назначения . Может случиться так, что вы меняете форматы так, как не знали. Модель базы данных, из которой вы переходите, также важна для выяснения этого.
источник
Как уже говорили другие, один из типов данных столбцов в исходной таблице больше, чем столбцы назначения.
Простое решение - просто отключить предупреждение и разрешить усечение. Итак, если вы получаете эту ошибку, но уверены, что данные в вашей старой базе данных / таблице допустимы для усечения (обрезки по размеру), вы можете просто сделать следующее;
Как и выше, всегда не забывайте снова включать предупреждения. Надеюсь, это поможет.
источник
Проблема довольно проста: один или несколько столбцов в исходном запросе содержат данные, длина которых превышает длину столбца назначения. Простое решение - взять исходный запрос и выполнить его
Max(Len( source col ))
в каждом столбце. То есть,Затем сравните эти длины с длинами типов данных в вашей целевой таблице. По крайней мере, один, превышает длину столбца назначения.
Если вы абсолютно уверены, что это не должно иметь место, и вам все равно, если это не так , то другое решение состоит в том, чтобы принудительно привести столбцы исходного запроса к их длине назначения (что приведет к обрезанию любых данных, которые являются слишком длинными):
источник
SQL Server 2019 наконец вернет более значимое сообщение об ошибке.
Для включения нового поведения вам нужно использовать
DBCC TRACEON(460)
. Новый текст ошибки отsys.messages
:Строковые или двоичные данные будут обрезаны: вместо печально известной ошибки 8152
SQL Server 2017 CU12 также поддерживает эту функцию.
Улучшение: Необязательная замена сообщения «Строка или двоичные данные будут усечены» с расширенной информацией в SQL Server 2017
db <> Fiddle demo
источник
Еще одна потенциальная причина этого заключается в том, что у вас есть настройка по умолчанию для столбца, длина которого превышает длину столбца. Похоже, кто-то толстый перебрал столбец, который имел длину 5, но значение по умолчанию превысило длину 5. Это сводило меня с ума, когда я пытался понять, почему он не работает ни на одной вставке, даже если все, что я вставлял, было один столбец с целым числом 1. Поскольку значение по умолчанию в схеме таблицы имело это нарушающее значение по умолчанию, оно все испортило - что, я думаю, подводит нас к извлеченному уроку - избегайте таблиц со значениями по умолчанию в схеме. :)
источник
Для других, также проверьте свою хранимую процедуру . В моем случае в моей хранимой процедуре
CustomSearch
я случайно объявил недостаточную длину для своего столбца, поэтому, когда я вводил большие данные, я получал эту ошибку, даже если в моей базе данных была большая длина. Я просто изменил длину моего столбца в моем пользовательском поиске, ошибка исчезла. Это только для напоминания. Спасибо.источник
Это может быть сложной ошибкой. Вот некоторые заметки, взятые с https://connect.microsoft.com/SQLServer/feedback/details/339410/, чтобы найти комментарий AmirCharania.
Я скорректировал ответ, данный AmirCharania, для данных, выбранных в фактическую таблицу, вместо временной. Сначала выберите ваш набор данных в таблицу разработки, а затем выполните следующее:
источник
Вот немного другой ответ. Все имена и длины столбцов могут совпадать, но, возможно, вы указали столбцы в неправильном порядке в своем операторе SELECT. Скажем, у tableX и tableY есть столбцы с одинаковым именем, но в разном порядке
источник
Я столкнулся с этой проблемой сегодня, и в моем поиске ответа на это минимальное информативное сообщение об ошибке я также нашел эту ссылку:
https://connect.microsoft.com/SQLServer/feedback/details/339410/please-fix-the-string-or-binary-data-would-be-truncated-message-to-give-the-column-name
Так что, похоже, у Microsoft нет планов по расширению сообщений об ошибках в ближайшее время.
Поэтому я обратился к другим средствам.
Я скопировал ошибки в Excel:
(Затронут 1 ряд)
(Затронут 1 ряд)
(Затронуты 1 строка) Сообщение 8152, уровень 16, состояние 14, строка 13 Строка или двоичные данные будут усечены. Заявление было прекращено.
(Затронут 1 ряд)
посчитал количество строк в Excel, приблизился к счетчику записей, который вызвал проблему ... скорректировал мой код экспорта, чтобы распечатать близкий к нему SQL ... затем запустил 5 - 10 sql вставок вокруг проблемы sql и удалось определить проблему, увидеть строку, которая была слишком длинной, увеличить размер этого столбца, а затем большой файл импорта не запустился.
Немного взлома и обходного пути, но когда у вас остается мало выбора, вы делаете то, что можете.
источник
Да, я тоже сталкиваюсь с такой проблемой.
Здесь я изменил длину поля ЗАМЕЧАНИЯ от 500 до 1000
источник
Я собираюсь добавить еще одну возможную причину этой ошибки только потому, что никто не упомянул об этом, и это могло бы помочь какому-нибудь будущему человеку (поскольку ОП нашел свой ответ). Если таблица, в которую вы вставляете, имеет триггеры, возможно, триггер генерирует ошибку. Я видел это, когда определения полей таблицы были изменены, а таблицы аудита - нет.
источник
Да - «пинта в полпинты не пойдет». Мне не очень повезло (по какой-то причине) с различными SP, которые предложили люди, НО, пока две таблицы находятся в одной БД (или вы можете поместить их в одну БД), вы можете использовать INFORMATION_SCHEMA. КОЛОННЫ, чтобы найти ошибочные поля, таким образом:
Это позволит вам прокручивать вверх и вниз, сравнивая длины полей по мере продвижения. Закомментированные разделы позволяют вам видеть (когда-то без комментариев, очевидно), есть ли несоответствия типов данных, или конкретно показывать те, которые отличаются по длине поля - потому что мне лень прокручивать - просто знайте, что все это основано на источнике имена столбцов, совпадающие с именами цели.
источник
Я использовал пустую строку «» при создании таблицы и затем получал сообщение об ошибке «Сообщение 8152, строка или двоичные данные будут обрезаны» при последующем обновлении. Это происходило из-за значения обновления, содержащего 6 символов, которое было больше ожидаемого определения столбца. Я использовал «ПРОБЕЛ», чтобы обойти это только потому, что знал, что я буду обновлять массово после первоначального создания данных, то есть столбец не будет оставаться пустым долго.
ТАК БОЛЬШОЕ ПРЕДУПРЕЖДЕНИЕ ЗДЕСЬ: Это не очень удобное решение, но оно полезно в том случае, когда вы собираете набор данных, например, для разовых аналитических запросов, когда вы создаете таблицу для интеллектуального анализа данных, применяя некоторую массовую обработку / интерпретацию и сохранение до и после результатов для последующего сравнения / майнинга. Это частое явление в моей работе.
Вы можете изначально заполнить, используя ключевое слово SPACE, т.е.
Последующие обновления «column_name» длиной не более 10 символов (замените при необходимости) будут разрешены без возникновения ошибки усечения. Опять же, я бы использовал это только в сценариях, аналогичных описанным в моем предупреждении.
источник
Я построил хранимую процедуру, которая анализирует исходную таблицу или запрос с несколькими характеристиками на столбец, среди которых минимальная длина (min_len) и максимальная длина (max_len).
Я храню эту процедуру в базе данных master, чтобы использовать ее в каждой базе данных следующим образом:
И вывод:
column description constraint_type fk_table fk_column pos default null data_type length precision radix is_unique min_len max_len nulls blanks numerics distincts distinct_values remarks
id_individual NULL PRIMARY KEY NULL NULL 1 NULL NO int NULL 10 10 1 1 2 0 0 70 70 Many (70) unique,all numeric,
id_brand NULL NULL NULL NULL 2 NULL NO int NULL 10 10 0 1 1 0 0 70 2 2,3 same length,all numeric, guid NULL NULL NULL NULL 3 (newid()) NO uniqueidentifier NULL NULL NULL 1 36 36 0 0 0 70 Many (70) unique,same length,
customer_id NULL NULL NULL NULL 4 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
email NULL NULL NULL NULL 5 NULL YES varchar 100 NULL NULL 0 4 36 0 0 0 31 Many (31)
mobile NULL NULL NULL NULL 6 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
initials NULL NULL NULL NULL 7 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
title_short NULL NULL NULL NULL 8 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
title_long NULL NULL NULL NULL 9 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
firstname NULL NULL NULL NULL 10 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
lastname NULL NULL NULL NULL 11 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
address NULL NULL NULL NULL 12 NULL YES varchar 100 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
pc NULL NULL NULL NULL 13 NULL YES varchar 10 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
kixcode NULL NULL NULL NULL 14 NULL YES varchar 20 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
date_created NULL NULL NULL NULL 15 (getdate()) NO datetime NULL NULL NULL 1 19 19 0 0 0 70 Many (70) unique,same length,
created_by NULL NULL NULL NULL 16 (user_name()) NO varchar 50 NULL NULL 0 13 13 0 0 0 1 loyalz-public same length,
id_location_created NULL FOREIGN KEY location id_location 17 NULL YES int NULL 10 10 0 1 1 0 0 70 2 1,2 same length,all numeric, id_individual_type NULL FOREIGN KEY individual_type id_individual_type 18 NULL YES int NULL 10 10 0 NULL NULL 70 0 0 0 NULL all null,empty,
optin NULL NULL NULL NULL 19 NULL YES int NULL 10 10 0 1 1 39 0 31 2 0,1 same length,
источник
sp_
префикс для ваших хранимых процедур. Microsoft зарезервировала этот префикс для собственного использования (см. Именование хранимых процедур ) , и вы рискуете столкнуться с именем в будущем. Это также плохо сказывается на производительности хранимых процедур . Лучше просто избегатьsp_
и использовать что-то другое в качестве префикса - или вообще без префикса!Я написал полезную процедуру хранения, которая поможет идентифицировать и решить проблему усечения текста (строка или двоичные данные будут усечены) при использовании оператора INSERT SELECT. Он сравнивает только поля CHAR, VARCHAR, NCHAR и NVARCHAR и возвращает поле оценки по полю в случае возможной причины ошибки.
КОД ФУНКЦИИ:
На данный момент поддерживаются только типы данных CHAR, VARCHAR, NCHAR и NVARCHAR . Вы можете найти последнюю версию этого кода в следующей ссылке ниже, и мы помогаем друг другу улучшить ее. GetFieldStringTruncate.sql
https://gist.github.com/jotapardo/210e85338f87507742701aa9d41cc51d
источник
Если вы используете SQL Server 2016-2017: чтобы исправить это, включите флаг трассировки 460
и убедитесь, что вы выключите его после:
источник
источник
это также может произойти, если у вас нет соответствующих разрешений
источник
У меня была похожая проблема. Я копировал данные из одной таблицы во все идентичные таблицы, кроме имени.
В конце концов я сбросил исходную таблицу во временную таблицу с помощью инструкции SELECT INTO.
Я сравнил схему исходной таблицы с временной таблицей. Я обнаружил, что одна из колонн была,
varchar(4000)
когда я ожидалvarchar(250)
.ОБНОВЛЕНИЕ: проблему varchar (4000) можно объяснить здесь, если вы заинтересованы:
Для Nvarchar (Max) я получаю только 4000 символов в TSQL?
Надеюсь это поможет.
источник
Эта ошибка выдается, когда в столбец таблицы накладывается ограничение [в основном длина]. , Например, если схема базы данных для столбца myColumn имеет вид CHAR (2), то при вызове любого из ваших приложений для вставки значения необходимо передать строку длины два.
Ошибка в основном говорит это; Строка длиной три и выше не соответствует ограничениям длины, заданным схемой базы данных. Вот почему SQL Server предупреждает и выдает ошибку потери данных / усечения.
источник
Пожалуйста, попробуйте следующий код:
источник