Что означает ошибка SQL Server «Строковые данные, усечение справа» и как ее исправить?
Мы проводим некоторые тесты производительности на нашем веб-сайте и часто получаем следующую ошибку:
*** 'C:\inetpub\foo.plex' log message at: 2008/10/07 13:19:58
DBD::ODBC::st execute failed: [Microsoft][SQL Native Client]String data, right truncation (SQL-22001) at C:\inetpub\foo.plex line 25.
Строка 25 следующая:
SELECT DISTINCT top 20 ZIP_CODE, CITY, STATE FROM Zipcodes WHERE (ZIP_CODE like ?) OR (CITY like ?) ORDER BY ZIP_CODE
И, наконец, это Perl-код.
Есть идеи?
РЕДАКТИРОВАТЬ: проблема заключалась в том, что я искал в zip-файле слишком длинную строку «74523%». Я закончил тем, что просто не добавил%, если они дают пять цифр.
Ответы 4
Либо параметр, предоставленный для ZIP_CODE, больше (по длине), чем ширина столбца ZIP_CODEs, либо параметр, предоставленный для CITY, больше (по длине), чем ширина столбца CITYs.
Было бы интересно узнать значения, указанные для двух заполнителей ?.
Я обошел проблему, используя convert для знака «?», Поэтому мой код выглядит как convert (char (50) ,?), и это избавило от ошибки усечения.
Это известная проблема драйвера ODBC mssql. Согласно сообщению в блоге Microsoft:
The ColumnSize parameter of SQLBindParameter refers to the number of characters in the SQL type, while BufferLength is the number of bytes in the application's buffer. However, if the SQL data type is varchar(n) or char(n), the application binds the parameter as SQL_C_CHAR or SQL_C_VARCHAR, and the character encoding of the client is UTF-8, you may get a "String data, right truncation" error from the driver even if the value of ColumnSize is aligned with the size of the data type on the server. This error occurs since conversions between character encodings may change the length of the data. For example, a right apostrophe character (U+2019) is encoded in CP-1252 as the single byte 0x92, but in UTF-8 as the 3-byte sequence 0xe2 0x80 0x99.
Вы можете найти полную статью здесь.
Примечательно, что это все еще проблема. Какие-нибудь обходные пути?
Я столкнулся с той же проблемой. Итак, я создал хранимую процедуру и определил размер как @FromDate datetime, @ToDate datetime, @BL varchar (50)
После определения размера в @BL varchar (50) у меня не возникло никаких проблем. Теперь все работает нормально
Интересно. Да, очевидно, это происходит, когда мы вводим полный почтовый индекс. Спасибо!