Почему не “Строка, или Двоичные данные были бы усеченными” более описательная ошибка?
Запускаться: Я понимаю то, что означает эта ошибка - я не пытаюсь разрешить экземпляр ее.
Эту ошибку известно трудно диагностировать, потому что, если Вы получаете ее вставляющий миллион строк в таблицу 100 столбцов шириной, нет фактически никакого способа определить, какой столбец того, какая строка вызывает ошибку - необходимо изменить процесс, чтобы вставить одну строку за один раз и затем видеть, какой перестал работать. Это - боль, выражаясь мягко.
Есть ли какая-либо причина, что ошибка не походит на больше это?
String or Binary data would be truncated
Error inserting value "Some 18 char value" into SomeTable.SomeColumn VARCHAR(10)
Это сделало бы намного легче найти и исправить значение, если не сама структура таблицы. Если наблюдение данных таблицы является проблемой безопасности, затем возможно, что-то универсальное, как предоставление длины предпринятого значения и названия провального столбца?
4 ответа
Оказывается, для этого есть открытый "запрос функции" в MS Connect - я бы посоветовал вам проголосовать за него, если вам нужна эта функциональность. измененный.
https://connect.microsoft.com/SQLServer/feedback/details/339410/
ДОБАВЛЕНО:
На самом деле похоже, что есть еще один запрос на ту же самую функцию (хотя и с неудачным названием), которая не выполнялась с тех пор, как Юкон разработка в 2005 году, за которую я бы также призвал людей голосовать:
https://connect.microsoft.com/SQLServer/feedback/details/125347/
Обновление 2016 года
Кажется, Microsoft пыталась удалите доказательства истинного возраста этой ошибки. Справедливо. Найдите старый сайт , заархивированный здесь.
Microsoft ленива?
Кстати, вам не нужно пробовать вставку каждой строки отдельно. Просто запросите max (len (field)) для каждого текстового столбца, начиная с тех, которые, как вы подозреваете, могут быть виноваты.
Короткий ответ: Так оно и есть.
Длинный ответ: Я мог бы увидеть смысл в показе номера строки и столбца, но, вероятно, не имело бы смысла показывать фактическую информацию, которая усекается. В случае со сценарием VARCHAR(10) это, вероятно, не имеет большого значения, но данные слишком большого размера были бы очень полезны. Но, надеюсь, никто здесь не вставляет ничего больше, чем может вместить VARCHAR(MAX) ;)
Описательные сообщения об ошибках в программных системах практически отсутствуют.
Это справедливо не только для СУБД, но и для любого программного обеспечения, которое только можно себе представить.
Я думаю, что основная причина в том, что реализация "хороших описательных сообщений об ошибках" требует слишком много времени. Это не является частью культуры среднего разработчика программного обеспечения - тратить много времени на размышления о том, «какую информацию пользователь хотел бы видеть, если возникнет этот конкретный вид исключения»? Программисты, которые должны написать код для выдачи «хороших описательных сообщений об ошибках», видят только стоимость (свое время), а не выгоду.
Одно из самых последних сообщений об ошибках, которые я получил от программной системы: «Произошла ошибка. Повторите попытку позже». Без шуток.