String or binary data would be truncated sqlstate 22001 error 8152

CREATE TABLE dbo.CoolPeople(PersonName VARCHAR(20), PrimaryCar VARCHAR(20));

GO

INSERT INTO dbo.CoolPeople(PersonName, PrimaryCar)

VALUES ('Baby', '2006 Subaru Impreza WRX GD');

GO

Машина Baby длиннее, чем 20 символов, поэтому при выполнении оператора INSERT получаем ошибку:

Msg 8152, Level 16, State 30, Line 5

String or binary data would be truncated.

The statement has been terminated.

Это засада, поскольку у нас нет идей относительно того, какое поле вызвало проблемы! Это особенно ужасно, когда вы пытаетесь вставить множество строк.

Чтобы пофиксить ошибку, включите флаг трассировки 460

Флаг трассировки 460 был введен в SQL Server Sevice Pack 2, Cummulative Update 6, и в SQL Server 2017. (Вы можете найти и загрузить последние обновления с SQLServerUpdates.com.) Вы можете включить флаг на уровне запроса, например:

INSERT INTO dbo.CoolPeople(PersonName, PrimaryCar)

VALUES ('Baby', '2006 Subaru Impreza WRX GD')

OPTION (QUERYTRACEON 460);

GO

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

Msg 2628, Level 16, State 1, Line 9

String or binary data would be truncated in 

table 'StackOverflow2013.dbo.CoolPeople', column 'PrimaryCar'. 

Truncated value: '2006 Subaru Impreza '.

Вы можете включить этот флаг трассировки как на уровне запроса (в нашем примере выше), так и на уровне сервера:

DBCC TRACEON(460, -1);

GO

Этот оператор включает его для всех, а не только для вас — поэтому сначала договоритесь со своей командой разработчиков, прежде чем включать его. Это изменит номер ошибки 8152 на 2628 (как показано выше), означающее, что если вы строили обработку ошибок на основании этих номеров, вы сразу получите другое поведение.

Я любитель включения этого флага трассировки на время отладки и изучения, но как только обнаруживаю источник проблем, выключаю его, снова выполнив команду:

DBCC TRACEON(460, -1);

GO

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

Не оставляйте этот флаг включенным

По крайней мере, имеется связанный с этим один баг в SQL Server 2017 CU13: табличные переменные будут выбрасывать ошибки, говорящие, что их содержимое усекается, даже если никакие данные не вставляются в них.

Вот простой скрипт, чтобы проверить, пофиксили ли это поведение:

CREATE OR ALTER PROC dbo.Repro @BigString VARCHAR(8000) AS

BEGIN

	DECLARE @Table TABLE ( SmallString VARCHAR(128) )

	IF ( 1 = 0 )

		/* Это никогда не выполняется */

		INSERT INTO @Table	( SmallString )

		VALUES(@BigString)

		OPTION (QUERYTRACEON 460)

END

GO

DECLARE @BigString VARCHAR(8000) = REPLICATE('blah',100)

EXEC dbo.Repro @BigString

GO

SQL Server 2017 CU13 всё еще сообщает об усечении строки, даже если строка не вставляется:

Переключение с табличной переменной на временную таблицу приводит к ожидаемому поведению:

Это замечательный пример, почему не следует использовать флаги трассировки по умолчанию. Конечно, они могут пофиксить проблемы, но они также могу вызвать непредсказуемое или нежелательное поведение. (И, вообще, я не фанат табличных переменных.)

SQL-Ex blog

Новости сайта «Упражнения SQL», статьи и переводы

Как исправить ошибку «Символьные или двоичные данные могут быть усечены»

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

Машина Baby длиннее, чем 20 символов, поэтому при выполнении оператора INSERT получаем ошибку:

Это засада, поскольку у нас нет идей относительно того, какое поле вызвало проблемы! Это особенно ужасно, когда вы пытаетесь вставить множество строк.

Чтобы пофиксить ошибку, включите флаг трассировки 460

Флаг трассировки 460 был введен в SQL Server Sevice Pack 2, Cummulative Update 6, и в SQL Server 2017. (Вы можете найти и загрузить последние обновления с SQLServerUpdates.com.) Вы можете включить флаг на уровне запроса, например:

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

Вы можете включить этот флаг трассировки как на уровне запроса (в нашем примере выше), так и на уровне сервера:

Этот оператор включает его для всех, а не только для вас — поэтому сначала договоритесь со своей командой разработчиков, прежде чем включать его. Это изменит номер ошибки 8152 на 2628 (как показано выше), означающее, что если вы строили обработку ошибок на основании этих номеров, вы сразу получите другое поведение.

Я любитель включения этого флага трассировки на время отладки и изучения, но как только обнаруживаю источник проблем, выключаю его, снова выполнив команду:

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

Не оставляйте этот флаг включенным

По крайней мере, имеется связанный с этим один баг в SQL Server 2017 CU13: табличные переменные будут выбрасывать ошибки, говорящие, что их содержимое усекается, даже если никакие данные не вставляются в них.

Вот простой скрипт, чтобы проверить, пофиксили ли это поведение:

SQL Server 2017 CU13 всё еще сообщает об усечении строки, даже если строка не вставляется:

Переключение с табличной переменной на временную таблицу приводит к ожидаемому поведению:

Это замечательный пример, почему не следует использовать флаги трассировки по умолчанию. Конечно, они могут пофиксить проблемы, но они также могу вызвать непредсказуемое или нежелательное поведение. (И, вообще, я не фанат табличных переменных.)

Обратные ссылки

Нет обратных ссылок

Комментарии

Показывать комментарии Как список | Древовидной структурой

Автор не разрешил комментировать эту запись

Источник

String or binary data would be truncated sqlstate 22001 error 8152

Вопрос

Здравствуйте, у меня на SCCM 2012 SP1 возникает следующая ошибка

*** [22001][8152][Microsoft][SQL Server Native Client 11.0][SQL Server]String or binary data would be truncated. : dINSTALLED_SOFTWARE_DATA

Как я понял? на SCCM сервер приходит отчет об инвентаризации програмного обеспечения, и сервер пытается эти данные записать в таблицу dINSTALLED_SOFTWARE_DATA на сиквел сервере. Но то ли в этом отчете есть длинные строчки, то ли целиком файл для sql большой, и сиквел не принимает данные от SCCM сервера

Я запустил на SQL сервере profiler, но он выдает ту же самую ошибку String or binary data would be truncated. Но что имено нужно обрезать, не говорит.

Можно ли узнать, что конкретно не нравится сиквелу во входящих данных?

Я в профайлере включил, в дополнение к стандартным данным, вывод всех ошибок.

Ответы

Для будущих поколений:

Проблема возникает при записи в таблицу INSTALLED_SOFTWARE_HIST, чье поле ServicePack00 имеет формат nvarchar(8), в то время в таблице, откуда копируются данные — INSTALLED_SOFTWARE_DATA — формат этого поля nvarchar(255).

Простое решение — это расширить проблемное поле до nvarchar(255), но без указки инженера Microsoft это переводит базу в состояние unsupported.

Проблема на самом деле заключается еще и в том, что в идеале в это поле никогда не должны писаться данные длиннее 1 символа. Если проверить содержимое этого поля после инвентаризации чистой машины, то там будет «1» в случае версии Service Pack 1. Однако в случае кастомных заливок в данных инвентаризации появляются 2 инстанса операционной системы, одна нормальная, вторая же содержит в этом поле «Service Pack 1» — 14 символов.

Источник появления второго инстанса ОС при инвентаризации WMI-класса Installed_Software пока неизвестен, скорее всего это какое-то расхождение в 32- и 64-хбитных ветках реестра HKLMSoftwareMicrosoftWindows NTCurrentVersion.

Правильное решение в этом случае: перезалить машину чистой проверенной заливкой или отключить инвентаризацию этого класса.

Тест машины на «кривость» — в консоли PS от имени администратора при установленном клиенте запустить: gwmi -namespace rootcimv2sms -query «select * from sms_installedsoftware
where Servicepack<>»»

Если выдается 1 инстанс — все хорошо, если два — машину стоит перезалить.

• Предложено в качестве ответа Pavel Yurenev Microsoft employee 9 октября 2013 г. 14:49
• Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 10 октября 2013 г. 4:57

нужно включить в Profiler отображение SP: STMTStarting ещё.

так как SQL: StmtStarting показывает только выполнение хранимой процедуры (например, dbo.dInstalled_Software_Data или dbo.pInstalled_Software_Data), а процедура, как оказалось, пишет не в одну таблицу, а в несколько разных, и SP: STMTStarting, как раз, показывает, какая таблица не может принять данные (в моем случае, это оказалась совершенно левая таблица).

Правда, не удалось разобраться, как узнать, какое поле при этом нужно увеличивать. Пришлось увеличить все nvarchar. Благо полей оказалось не так много.

• Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 28 мая 2013 г. 14:15

Все ответы

Достаточно в профайлере добавить 2 события:

SQL: BatchStarting и Exception

Msg 8152, Level 16, State 14, Line 1 String or binary data would be truncated.

The statement has been terminated.

Вот этот SQL:BatchStarting содержит данные вида

exec dbo.dINSTALLED_SOFTWARE_DATA 4,16777259,’05/27/2013 10:05:27′,1,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,N’‘,NULL,N’Microsoft Visual C++ 2008 Redistributable — x86 9.0.30729.4148′,N’9.0.30729.4148′,NULL,NULL,NULL,N’<1f1c2dfc-2d24-3e06-bcb8-725134adf989>‘,NULL,NULL,N’MsiExec.exe /X<1f1c2dfc-2d24-3e06-bcb8-725134adf989>‘,NULL,NULL,NULL exec dbo.dINSTALLED_SOFTWARE_DATA 4,16777259,’05/27/2013 10:05:27′,1,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,N’‘,NULL,N’Microsoft Visual C++ 2010 x86 Redistributable — 10.0.30319′,N’10.0.30319′,NULL,NULL,NULL,N’<196bb40d-1578-3d01-b289-befc77a11a1e>‘,NULL,NULL,N’MsiExec.exe /X<196bb40d-1578-3d01-b289-befc77a11a1e>‘,NULL,NULL,NULL exec dbo.dINSTALLED_SOFTWARE_DATA 4,16777259,’05/27/2013 10:05:27′,1,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,N’<6b1a624c-dedd-4728-8f85-04f648ae1262>‘,N’1′,N’КОМПАС-3D V13′,N’13.0.2′,NULL,NULL,NULL,N’‘,NULL,NULL,N’MsiExec.exe /I‘,NULL,NULL,NULL

и таких данных несколько экранов. Просто я не совсем в курсе этой ошибки. Она значит, что значение в каком-то столбце превышает допустимую длину переменной, или это может значить, что стоит null, а null запрещен, или несовпадает формат даты времени, или вот эти несколько страниц данных нельзя запихивать в сиквел одновременно?

По поводу первого, скорее всего нет, так как я смотрел, самая большая строчка 180 символов, а переменная nvarchar(255).

По поводу остального, не знаю как проверить.

Да, в одной такой записи, после exec.dbo стоят и другие таблицы из той же базы. И exeption звучит имено так

String or binary data would be truncated.

А про номер ошибки я могу узнать только из логов SCCM. Вряд ли он сам знает, что это за ошибка. Скорее всего ему эти данные дает SQL. А вот где они записаны, не понятно. В тех логах которые я включил, про 8152 ничего нет.

После этого exeption идут другие, так как запись в эту таблицу (dINSTALLED_SOFTWARE_DATA) не произошла, начинают сыпаться ошибки про таблицу содержащую суммарные данные и т.д. (Там кстати ошибка вполне конкретная: Cannot insert the value NULL into column ‘RevisionID’, table ‘CM_OPT.dbo.INSTALLED_SOFTWARE_HIST’; column does not allow nulls. INSERT fails.) Но это из-за того, что не произошла вставка первоночальных данных.

но там 15 столбцов, какой именно столбец не подходит?

И как я понял нельзя руками менять длинну переменной?

но там 15 столбцов, какой именно столбец не подходит?

И как я понял нельзя руками менять длинну переменной?

1) какой столбец вам придётся определить самостоятельно, проанализировав входные данные и размерность полей таблицы

2) что вы имеете в виду?

1) данные я проанализировал, они меньше длинны переменной. Ну, насколько это возможно, там несколько мегабайт данных, может быть что-то и пропустил.

А нет ли возможности определить это автоматически?

2) я могу в таблице выделить любой столбец, нажать изменить и поменять тип переменной, нпример, вместо nvarchar(255) поставить nvarchar(511). Но где-то было написано, что так лучше не делать.

1) данные я проанализировал, они меньше длинны переменной. Ну, насколько это возможно, там несколько мегабайт данных, может быть что-то и пропустил.

А нет ли возможности определить это автоматически?

2) я могу в таблице выделить любой столбец, нажать изменить и поменять тип переменной, нпример, вместо nvarchar(255) поставить nvarchar(511). Но где-то было написано, что так лучше не делать.

ошибка, которую вы получаете связана с размером полей, а не переменных.

изменение размерности поля в таблице — это штатная ситуация

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

Если нажать кнопку изменить на столбце, то я вижу название столбца, его data type, и может быть он null или нет.

Data type для столбца я изменить не могу, так как в этом случае будет пересоздана вся таблица, а в её свойствах запрещено пересоздание.

Altering a Column Definition

• A. Changing the data type of a column
• B. Changing the size of a column

Спасибо, но не помогло. Ошибка осталась.

Да, действительно, ошибка осталась, но блоков данных стало приниматься больше. То есть SCCM передает данные блоками, и раньше сиквел падал на третьем блоке, а теперь на седьмом.

Но это как иголку в стоге сена 🙁 несколько сотен баз и половина полей в них не хочет увеличиваться.

Как я понял раньше (до 2012 версии) сиквел посылал конкретные сообщения в SCCM — вот этот столбец слишком узкий, а тот, в свою очередь, посылал сиквелу alter этот столбец. A теперь безликая ошибка и соответственно автоматически ситуацию не исправить.

Про set ansi_warnings

насколько я понял, это относится к INSERT и UPDATE. А в моем случае EXEC.

насколько я понял, это относится к INSERT и UPDATE. А в моем случае EXEC.

Сам по себе exec ничего не вставляет, вставка осуществляется через команду INSERT, поэтому вам достаточно в процедуру добавить эту настройку и все вставки пройдут без ошибок, НО(!) имейте в виду, что вы потеряете часть данных т.к. они усекутся под размер ваших полей.

И всё-таки не думаю, что так уж сложно найти в какое поле не могут быть записаны данные, профайлер в руки и несколько минут вашего времени должны помочь найти причину!

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

А если потом появится новый клиент со специфическим ПО или драйвером и нужно заново проверять все триста полей.

Что-то тут не так.

Спасибо, будем искать специалиста.

Но всё равно спасибо за помощь.

нужно включить в Profiler отображение SP: STMTStarting ещё.

так как SQL: StmtStarting показывает только выполнение хранимой процедуры (например, dbo.dInstalled_Software_Data или dbo.pInstalled_Software_Data), а процедура, как оказалось, пишет не в одну таблицу, а в несколько разных, и SP: STMTStarting, как раз, показывает, какая таблица не может принять данные (в моем случае, это оказалась совершенно левая таблица).

Правда, не удалось разобраться, как узнать, какое поле при этом нужно увеличивать. Пришлось увеличить все nvarchar. Благо полей оказалось не так много.

• Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 28 мая 2013 г. 14:15

Для будущих поколений:

Проблема возникает при записи в таблицу INSTALLED_SOFTWARE_HIST, чье поле ServicePack00 имеет формат nvarchar(8), в то время в таблице, откуда копируются данные — INSTALLED_SOFTWARE_DATA — формат этого поля nvarchar(255).

Простое решение — это расширить проблемное поле до nvarchar(255), но без указки инженера Microsoft это переводит базу в состояние unsupported.

Проблема на самом деле заключается еще и в том, что в идеале в это поле никогда не должны писаться данные длиннее 1 символа. Если проверить содержимое этого поля после инвентаризации чистой машины, то там будет «1» в случае версии Service Pack 1. Однако в случае кастомных заливок в данных инвентаризации появляются 2 инстанса операционной системы, одна нормальная, вторая же содержит в этом поле «Service Pack 1» — 14 символов.

Источник появления второго инстанса ОС при инвентаризации WMI-класса Installed_Software пока неизвестен, скорее всего это какое-то расхождение в 32- и 64-хбитных ветках реестра HKLMSoftwareMicrosoftWindows NTCurrentVersion.

Правильное решение в этом случае: перезалить машину чистой проверенной заливкой или отключить инвентаризацию этого класса.

Тест машины на «кривость» — в консоли PS от имени администратора при установленном клиенте запустить: gwmi -namespace rootcimv2sms -query «select * from sms_installedsoftware
where Servicepack<>»»

Если выдается 1 инстанс — все хорошо, если два — машину стоит перезалить.

• Предложено в качестве ответа Pavel Yurenev Microsoft employee 9 октября 2013 г. 14:49
• Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 10 октября 2013 г. 4:57

Неужели я такой счастливчик, что единственный словил этот баг.

А не подскажете как зарегистрировать можно?

А не подскажете как зарегистрировать можно?

В R2 точно не поправлено, т.к. не зарегистрировано как баг. Sad but true.

Большое спасибо, у меня руки так и не дошли зарегистрировать баг.

Правильное решение в этом случае: перезалить машину чистой проверенной заливкой или отключить инвентаризацию этого класса.

Попробовал на паре(20) машин, данные обновились:

1. Делаем коллекцию из старых машин(старые данные HardwareInventory):

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_WORKSTATION_STATUS on SMS_G_System_WORKSTATION_STATUS.ResourceId = SMS_R_System.ResourceId where SMS_G_System_WORKSTATION_STATUS.LastHardwareScan

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

Если честно, если Вы поменяете базу самостоятельно, с вероятностью 95% проблем не будет, а инженер поддержки этого попросту не заметит, если Вы сами ему не расскажете. 🙂

P.S. Фикс отложили на следующий релиз SCCM, который выйдет в 2015 году.

Столкнулся с такой же проблемой на SCCM 2012 R2 5.00.7958.1000.
Машины залиты проверенным, созданным и залитым через SCCM образом ОС Windows 7.
Проблема возникла словно сама собой месяца три назад, т.к. классы инвентаризации не менялись.
Сейчас проблемных машин — 80%.

1. Как мне получить это одобрение на модификацию БД (куплен EAS)?
2. Где можно увидеть в каком состоянии БД «unsupported» или «supported»?
3. Если она перейдет с состояние «unsupported» (после изменения длинны поля) — чем это чревато?
4. Где можно найти официальное описание/статус зарегистрированного бага SCCM 2012 R2 «bug (SMS 410599)» — «SMS_INVENTORY_DATA_LOADER Microsoft SQL Server 8152 SQL issued a message, the importance of 16: [22001] [8152] [Microsoft] [SQL Server Native Client 11.0] [SQL Server] String or binary data would be truncated. : pINSTALLED_SOFTWARE_DATA«?

Проблема возникает при записи в таблицу INSTALLED_SOFTWARE_HIST, чье поле ServicePack00 имеет формат nvarchar(8), в то время в таблице, откуда копируются данные — INSTALLED_SOFTWARE_DATA — формат этого поля nvarchar(255).

Простое решение — это расширить проблемное поле до nvarchar(255), но без указки инженера Microsoft это переводит базу в состояние unsupported.

Проблема на самом деле заключается еще и в том, что в идеале в это поле никогда не должны писаться данные длиннее 1 символа. Если проверить содержимое этого поля после инвентаризации чистой машины, то там будет «1» в случае версии Service Pack 1. Однако в случае кастомных заливок в данных инвентаризации появляются 2 инстанса операционной системы, одна нормальная, вторая же содержит в этом поле «Service Pack 1» — 14 символов.

Источник появления второго инстанса ОС при инвентаризации WMI-класса Installed_Software пока неизвестен, скорее всего это какое-то расхождение в 32- и 64-хбитных ветках реестра HKLMSoftwareMicrosoftWindows NTCurrentVersion.

Правильное решение в этом случае: перезалить машину чистой проверенной заливкой или отключить инвентаризацию этого класса.

Тест машины на «кривость» — в консоли PS от имени администратора при установленном клиенте запустить: gwmi -namespace rootcimv2sms -query «select * from sms_installedsoftware
where Servicepack<>»»

Если выдается 1 инстанс — все хорошо, если два — машину стоит перезалить.

А какой тут у меня инстанс на скриншоте, Подскажите.

Источник

In this SQL Server tutorial, we will understand the “String or binary data would be truncated” error in a SQL Server 2019, and we will also learn how to resolve this error. For this, we will cover the following topics.

• String or binary data would be truncated SQL Server Error
• String or binary data would be truncated SQL Server Which Column
• How to fix “String or binary data would be truncated”
• String or binary data would be truncated SQL Server 2019
• String or binary data would be truncated Datetime SQL Server
• String or binary data would be truncated in SQL Server Stored Procedure

This error usually occurs when we try to insert more data into a column than the specified column can store. Let’s understand this with the help of an example.

CREATE TABLE Sample (
	id INT,
	Name VARCHAR(10),
	gender VARCHAR(8)
);
insert into Sample (id, Name, gender) values (1, 'Maurits Hessing', 'Agender');

In the example, we are creating a table with 3 columns in it, and for the Name column, we have defined the data type as “VARCHAR(10)“. It means that the Name column can hold a string having 10 characters.

But while inserting a value into the table, we have specified the value for the Name column with 15 characters which is more than 10.

So the above query will return the following error.

Read SQL Server bulk insert from CSV file

String or binary data would be truncated SQL Server Which Column

Till now, we have understood the reason why we are getting this error. Now let’s understand how we can find the column due to which we are getting the error.

In SQL Server 2019, Microsoft has updated the error message for this error. For SQL Server 2019, the error message not only returns the column name but also returns the table for which the error has been encountered.

For demonstration, consider the error message that we have shown in the previous section.

Now, if we read the error message thoroughly, we will easily get the column name for which the error has been encountered.

If you have upgraded from some previous SQL Server version to SQL Server 2019. Then you might need to execute the following query in the database where you want a complete truncate warning.

ALTER DATABASE SCOPED CONFIGURATION 
SET VERBOSE_TRUNCATION_WARNINGS = ON;

And for SQL Server 2016/2017, we have to turn on the trace flag 460. And to enable the trace flag 460, we can execute the following query while inserting or updated table records.

insert into Sample (id, Name, gender) values (1, 'Maurits Hessing', 'Agender')
OPTION (QUERYTRACEON 460);

Now by enabling the trace flag 460, the SQL Server will return a detailed truncation warning, from which we can easily identify the column name.

Read: Identity Column in SQL Server

How to fix “String or binary data would be truncated”

The main reason behind this error is the more amount of data that we are trying to store in a column than a specific column can store. So a quick solution to solve this error is by increase the column size. For this, we can use the ALTER TABLE command and increase the column size.

For demonstration, consider the following query, used to modify the column size of the sample table.

--Modifying Table
ALTER TABLE Sample
ALTER COLUMN Name VARCHAR(20)
GO

--Inserting the new record
insert into Sample (id, Name, gender) values (1, 'Maurits Hessing', 'Agender')
GO

In the above example, first, we are using the ALTER TABLE and ALTER COLUMN statements to modify the size of the column. After this, we are using the INSERT statement to insert a new record. And if the inserted value is less than or equal to the size of the column, then the new record will be inserted successfully.

Read: Create Foreign Key in SQL Server

String or binary data would be truncated SQL Server 2019

While using SQL Server earlier versions, if we try to insert more data than specified for a column, we get the following error.

Now, this error message is not much helpful in debugging the issue. For this, we have to manually check the query to find and resolve the error.

But Microsoft has made some enhancements for this error message in SQL Server 2019. So, in SQL Server 2019, if this error has been encountered, the SQL Server will return a detailed truncate warning.

The column name, table name, even the value for which the error has been raised is mentioned in the error message. The example is already shown in the “String or binary data would be truncated SQL Server Which Column” topic.

If you are already using SQL Server 2019, but still not getting the detailed error message. Then execute the following query in the database where you want a complete truncate warning.

ALTER DATABASE SCOPED CONFIGURATION 
SET VERBOSE_TRUNCATION_WARNINGS = ON;

String or binary data would be truncated Datetime SQL Server

This issue commonly occurs when entering a record into a table with a VARCHAR or CHAR data type column and a value is longer than the column’s length. We will not get this error in the case of a Datetime datatype.

In the case of the DateTime data type, if we try to insert a longer value than the column size then the column will ignore the extra characters and save the value.

Now for demonstration, consider the following example given below.

--Creating table
CREATE TABLE Sample (
	id INT,
	Name VARCHAR(50),
	Joining_date DATETIME
);

--inserting values
insert into Sample (id, Name, Joining_date) values (1, 'Modesty Malley', SYSDATETIME());

• In the example, we are creating a table named “Sample” with 3 columns.
• Out of these 3 columns, we have defined the “Joining_date” column to be a DateTime column.
• Now, the Datetime column has a default fractional precision of 3, which means it can store a maximum of 3 characters in nanoseconds part (yyyy-mm-dd hh:mm:ss:nnn).
• But while inserting values, we are using the SYSDATETIME() function which returns the current date-time value in Datetime2 format. The SYSDATETIME() will return the date-time value with a fractional seconds precision of 7 (yyyy-mm-dd hh:mm:ss:nnnnnnn).
• But still, the value got successfully inserted in the Datetime column, but it has ignored the last 4 characters.

Read: Types of Backup in SQL Server

String or binary data would be truncated in SQL Server Stored Procedure

This error can also occur while executing a stored procedure in SQL Server, which is trying to insert new values in a column. But still, the reason behind this error will remain the same i.e, the column length is less than the value length that we are trying to insert.

Let’s understand this with the help of an example. And for this, we are using the following query to create a sample table.

--Creating table
CREATE TABLE Sample (
	id INT,
	Name VARCHAR(5),
	Joining_date DATETIME
);

Now take a look at the Name column, for the Name column we have defined the character length to be 5.

Next, we are using the following stored procedure to insert new records in the sample table.

ALTER PROCEDURE Insert_data
AS
--inserting values
insert into Sample (id, Name, Joining_date) values (1, 'Modesty Malley', GETDATE());

GO

Exec Insert_data

But while inserting the record through the stored procedure, we have specified the name value to be 14 characters. So, if we try to execute this procedure, we will get the following error.

And the simplest solution to resolve this error is by modifying the column and increasing the column length. This solution is already been discussed in the topic above.

You may like the following SQL server tutorials:

• SQL Server Row_Number
• SQL Server Add Column + Examples
• IDENTITY_INSERT in SQL Server
• SQL Server stored procedure output parameter

So in this SQL Server tutorial, we have learned how to solve the “String or binary data would be truncated” error in a SQL Server, and we have also covered the below topics.

• String or binary data would be truncated SQL Server Error
• String or binary data would be truncated SQL Server Which Column
• How to fix “String or binary data would be truncated”
• String or binary data would be truncated SQL Server 2019
• String or binary data would be truncated Datetime SQL Server
• String or binary data would be truncated in SQL Server Stored Procedure

I am Bijay having more than 15 years of experience in the Software Industry. During this time, I have worked on MariaDB and used it in a lot of projects. Most of our readers are from the United States, Canada, United Kingdom, Australia, New Zealand, etc.

Want to learn MariaDB? Check out all the articles and tutorials that I wrote on MariaDB. Also, I am a Microsoft MVP.

You receive following error message, which admittedly is not very helpful:

Msg 8152, Level 16, State 30, Line 13
String or binary data would be truncated.
The statement has been terminated.

We heard that. Which is why SQL Server 2019 introduces a new message , with additional context information. For the same operation, the new error message outputs the following:

Msg 2628, Level 16, State 1, Line 14
String or binary data would be truncated in table ‘AdventureWorks2016CTP3.Sales.SalesOrderHeaderTest’, column ‘CreditCardApprovalCode’. Truncated value: ‘1231736Vi8604’.
The statement has been terminated.

Ok, the new error message provides more context, and now I have the resulting truncated value (not the source value). This is simplifying the troubleshooting process, because now I know the truncated value starts with ‘1231736Vi8604′ – that’s 13 characters. And so I can go back to my data source, and locate the source record and its length:

SELECT [SalesOrderID], [CustomerID], [CreditCardApprovalCode], LEN([CreditCardApprovalCode])
FROM [Sales].[SalesOrderHeader]
WHERE CreditCardApprovalCode LIKE ‘1231736Vi8604%’

CREATE TABLE myTable (myString VARCHAR(120));
GO
INSERT INTO myTable
VALUES (‘Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.’)
GO

Although my string gets truncated at 120 characters, the offending value that is shown is truncated to the first 100 characters:

Msg 2628, Level 16, State 1, Line 30
String or binary data would be truncated in table ‘AdventureWorks2016CTP3.dbo.myTable’, column ‘myString’. Truncated value: ‘Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore ‘.