Как сохранить входные данные хранимой процедуры от тихого усечения?

Question

Мы используем стандартные System.Data классы, DbConnection и DbCommand, для подключения к SQL Server из C #, и у нас есть много хранимых процедур, которые принимают VARCHAR или NVARCHAR параметры в качестве входных данных.Мы обнаружили, что ни SQL Server, ни наше приложение C # не выдают никаких ошибок или предупреждений, когда в качестве значения этого параметра передается строка, длина которой превышает максимальную длину параметра.Вместо этого значение молча усекается до максимальной длины параметра.

Так, например, если вход хранимой процедуры имеет тип VARCHAR(10), и мы передаем 'U R PRETTY STUPID', хранимая процедура получает вход как 'U R PRETTY', что очень хорошо, но совершенно не то, что мыхотел сказать.

То, что я сделал в прошлом для обнаружения этих усечений, и что другие также предложили , это сделать длину входного параметра на один символ больше, чем требуется, изатем проверьте, равна ли длина ввода этой новой максимальной длине.Таким образом, в приведенном выше примере мой ввод будет VARCHAR(11), и я буду проверять ввод длины 11. Любой ввод длиной 11 или более будет пойман этой проверкой.Это работает, но чувствует себя неправильно.В идеале уровень доступа к данным должен автоматически обнаруживать эти проблемы.

Есть ли лучший способ определить, что входная информация для хранимой процедуры длиннее допустимой?Разве DbCommand не должен уже знать об ограничениях входной длины?

Кроме того, из любопытства, что ответственно за молчаливое усечение наших входных данных?

Answer 1

Используйте VARCHAR(8000), NVARCHAR(4000) или даже N/VARCHAR(MAX) для всех переменных и параметров.Таким образом, вам не нужно беспокоиться об усечении при назначении @variables и @parameters.Усечение может произойти при реальной записи данных (вставка или обновление), но это не означает, что произойдет серьезная ошибка, и вы узнаете об этом.Вы также получаете дополнительное преимущество, заключающееся в том, что код хранимой процедуры не нужно изменять при изменении схемы (изменение длины столбца, код по-прежнему действителен).Кроме того, вы получите лучшее поведение при планировании кэша благодаря использованию согласованных длин параметров, см. Как код доступа к данным влияет на производительность базы данных .

Имейте в виду, что при использовании типов MAX для @ наблюдается небольшое снижение производительности.переменные / @ параметры, см. Сравнение производительности varchar (max) и varchar (N) .