Sql error 8152 sqlstate 22001

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 инстанс — все хорошо, если два — машину стоит перезалить.

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

Источник

Apparently, there are some common errors that you may get on your Windows PC. One of them is SQL Error 8152. As a Windows user, you should know more regarding the SQL Error 8152. What is the Error 8152? What cause of the SQL error 8152? and how to fix the error? Find out that information here.

ABOUT SQL ERROR 8152

Based on the research, the SQL Error 8152 is well known as the String or Binary Data would be truncated error. Actually, it is one of common errors. You have to know that the SQL Error 8152 usually occurs when a user tries to insert any data in string such as char,nchar, varchar, or nvarchar more than the size of the column. 

For this case, a user needs to check the data size with respect to the column width and identify which column is making the error and then fix it.

• More info: PowerShell Foreach vs Foreach-Object Comparison

CAUSE OF THE SQL ERROR 8152

Apparently, the SQL Error 8152 error occurs when the value insisted in a field is bigger than the one the database column max value allows. For instance, if there is a simple text field which by default generates a 257 max char column in the database, the error is going to be thrown if entering in this field 258+ characters.

HOW TO FIX THE SQL ERROR 8152

We are able to say that the SQL Error 8152 occurs when C#(model) try to save data records for columns whose size is defined less in SQL SERVER database table where the value to pass to this column string length in bigger. To fix the SQL error 8152 you have to change column of the table in SQL SERVER database by using SQL Server script. You only need to increase the size of the column in table works. Do not need to remove the application in the test environment.

In fact, it is easy enough if you are dealing with less columns in a table. However, it is going to become a nightmare if you are dealing with insert into a query with a big number of columns. It means that you need to check one by one column. 

We get information that there is a shortcut to fix the SQL Error 8152 and provide the column name along with the data making error. We started looking for the solution, but we could not get a correct one. Therefore, we started making the following solution.

Before doing with the solution, you would like to make a simple sample to demonstrate the error. After that, you have to look at the column and see its size.

To fix the SQL Error 8152, you are able to follow these easy steps below:

• Firstly, you need to pass the string value less than or equal to its size.
• If you want to compress the error, you have to set the ansi warnings parameter to off.
• If you use the ansi_warnings parameter as off, then the SQL Error 8152 will be compressed and whatever is able to suitable in the column.
• The string test is going to be save in your table. Now, it will not get back any error.

Apparently, The error message does not contain adequate information about which is the field length value is making the error. To determine which field value which is making the error, you need to improve the data which is entered when you are making the content. 

Aside from that, you also need to trim out the values of the fields one by one until the saving of the content passed successfully. If the error happens for the made through the backend, you will be able to go through the field inputs and remove the values one by one and then perform the saving operation after each deletion until the saving is successful. 

But, if the error happens for the items made through the API, you have to go through the values received as an input or static values that were set in the code and then perform the same process of deleting values one by one.

Please understand what text field of the document contains the long string that prevents the document publish refer to the file DocumentExtractor.zip. You have to know that it contains a webform with Sitefinity API that will report on the length of the string properties of the document and show them to the user. 

Doing this way, easily it will be able to be determine which field contains many symbols. Now, we are going to explain how to use the DocumentExtractor. Apparently, there are some easy steps that you have to do in using the DocumentExtractor.

• Don’t miss: What is Uncaught Syntaxerror: Cannot Use Import Statement Outside a Module?

• At the first step, you have to add it to the website files. Remember that it does not need compilation. In this case, you only need to add it and then use it directly by requesting it via URL.
• The second step that you have to do is to log in to Sitefinity with a user who has permissions to manage the documents.
• Now, you have to fill in the textbox with the name of the Document Library where this document is. For note: If the document is in subfolders under the top library do not care about those, the top level library is enough.
• The next step is to fill in the textbox for the document Title and the language in which the error happens. If the site does not utilize multiple languages (in case it has only the default language EN), so you are able to let us know and try later.
• Now, the form will output the details for the document and its text properties as well their length.

Well, this is an explanation regarding what the SQL Error 8152 is, what cause of the SQL error 8152, and how to fix the SQL Error 8152. When you get this SQL Error 8152, do not hesitate to try doing those steps above. Make sure that you perform steps by steps completely so that the error will be fixed.

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 всё еще сообщает об усечении строки, даже если строка не вставляется:

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

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