SQLException: строка или двоичные данные будут усечены

Question

У меня есть код C #, который выполняет много операций вставки в пакет. Выполняя эти операторы, я получил сообщение об ошибке «Строка или двоичные данные будут обрезаны» и транзакция откатилась назад.

Чтобы выяснить, какой оператор вставки вызвал это, мне нужно вставлять один за другим в SQLServer, пока не возникнет ошибка.

Есть ли умный способ выяснить, какой оператор и какое поле вызвало эту проблему, используя обработку исключений? (SqlException)

Answer 1

Как правило, нет способа определить, какой именно оператор вызвал ошибку. Если вы работаете с несколькими, вы можете посмотреть профилировщик и посмотреть последний завершенный оператор и посмотреть, каким может быть этот оператор после этого, хотя я не знаю, выполним ли этот подход для вас.

В любом случае, одна из ваших переменных параметров (и данных внутри нее) слишком велика для поля, в котором она пытается сохранить данные. Проверьте размеры ваших параметров по размерам столбцов, и соответствующие поля должны быть очевидными. довольно быстро.

Answer 2

Этот тип ошибки возникает, когда тип данных столбца SQL Server имеет длину, которая меньше длины данных, введенных в форму ввода.

Answer 3

этот тип ошибки обычно возникает, когда вам нужно поместить символы или значения больше, чем вы указали в таблице базы данных, как в этом случае: вы указываете транзакция_статус varchar (10) но вы на самом деле пытаетесь хранить _transaction_status которые содержат 19 символов. вот почему вы столкнулись с этим типом ошибки в этом коде

Answer 4

Как правило, вы вставляете значение, которое больше максимально допустимого значения. Например, столбец данных может содержать до 200 символов, но вы вставляете строку из 201 символа

Answer 5

BEGIN TRY
    INSERT INTO YourTable (col1, col2) VALUES (@val1, @val2)
END TRY
BEGIN CATCH
    --print or insert into error log or return param or etc...
    PRINT '@val1='+ISNULL(CONVERT(varchar,@val1),'')
    PRINT '@val2='+ISNULL(CONVERT(varchar,@val2),'')
END CATCH

Answer 6

1. Получить запрос, который вызывает проблемы (вы также можете использовать SQL Profiler, если у вас нет источника)
2. Удалите все предложения WHERE и другие неважные части, пока в основном не останетесь только части SELECT и FROM
3. Добавить WHERE 0 = 1 (при этом будет выбрана только структура таблицы)
4. Добавить INTO [MyTempTable] непосредственно перед предложением FROM

У вас должно получиться что-то вроде

SELECT
 Col1, Col2, ..., [ColN]
INTO [MyTempTable]
FROM
  [Tables etc.]
WHERE 0 = 1

Это создаст таблицу с именем MyTempTable в вашей БД, которую вы сможете сравнить со структурой вашей целевой таблицы, т.е. вы можете сравнить столбцы в обеих таблицах, чтобы увидеть, где они отличаются. Это немного обходной путь, но это самый быстрый метод, который я нашел.

Answer 7

Это зависит от того, как вы делаете вставки вызовов. Все как один звонок или как отдельные звонки внутри транзакции? Если отдельные вызовы, то да (когда вы перебираете вызовы, найдите тот, который не прошел). Если один большой звонок, то нет. SQL обрабатывает весь оператор, поэтому он не в руках кода.

Answer 8

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

Несколько раз меня укусило, когда я пошел в SQL Management Studio, быстро:

sp_help 'mytable'

и запутайтесь в течение нескольких минут, пока я не пойму, что рассматриваемый столбец - nvarchar , что означает, что длина, сообщаемая sp_help, действительно вдвое больше реальной поддерживаемой длины, потому что это двухбайтовый (Unicode) тип данных .

т.е. если sp_help сообщает nvarchar Length 40, вы можете сохранить максимум 20 символов.

Answer 9

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

Answer 10

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