SQL 服務器錯誤“字符串數據，右截斷”是什么意思，我該如何解決？

Question

我們正在我們的網站上進行一些性能測試，我們經常收到以下錯誤：

*** '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%”太長了。 如果他們給出五位數，我最終只是不添加 %。

Answer 1

為ZIP_CODE提供的參數（長度）大於ZIP_CODE的列寬，或者為CITY提供的參數（長度）大於CITY的列寬度。

知道為兩者提供的值會很有趣? 占位符。

Answer 2

這是 mssql ODBC 驅動程序的已知問題。 根據微軟博客文章：

SQLBindParameter 的 ColumnSize 參數指的是 SQL 類型中的字符數，而 BufferLength 是應用程序緩沖區中的字節數。 但是，如果SQL數據類型為varchar(n)或char(n)，應用程序將參數綁定為SQL_C_CHAR或SQL_C_VARCHAR，而客戶端的字符編碼為UTF-8，則可能會得到“String data, right truncation” " 即使 ColumnSize 的值與服務器上數據類型的大小對齊，驅動程序也會出錯。 發生此錯誤是因為字符編碼之間的轉換可能會更改數據的長度。 例如，右撇號字符 (U+2019) 在 CP-1252 中編碼為單字節 0x92，但在 UTF-8 中編碼為 3 字節序列 0xe2 0x80 0x99。

您可以在此處找到完整的文章。

Answer 3

我通過在“？”上使用轉換來解決這個問題，所以我的代碼看起來像 convert(char(50),?) 並且擺脫了截斷錯誤。

Answer 4

我面臨着同樣的問題。 所以，我創建了一個存儲過程並定義了大小，如@FromDate datetime、@ToDate datetime、@BL varchar(50)

在@BL varchar(50) 中定義大小后，我沒有遇到任何問題。 現在它工作正常

Answer 5

如果連接是通過 PHP 完成的，我們使用連接參數“CharacterSet”解決：

sqlsrv_connect(DB_PTH_HOST, array(
                                "Database" => ***,
                                "UID" => ***,
                                "PWD" => ***,
                                "CharacterSet" => "UTF-8"));

Answer 6

我今天在一個已經運行多年的應用程序上體驗到了這一點。 我的事業有點不同，所以我想我會分享以幫助將來發生這種情況的任何人。

對於我遇到的問題，我們有一個在客戶端計算機上運行的應用程序，客戶端通過 ODBC 連接與數據庫服務器通信。 無論出於何種原因，客戶端上的 ODBC 驅動程序已更新為比服務器更新的版本（過去通常無關緊要）。 該版本僅相隔 1 個月，但卻是問題的原因。 我轉到 windows 補丁歷史並卸載了日期與 ODBC 驅動程序日期最接近的補丁，這解決了問題。 （要查看ODBC驅動版本，只需在windows開始搜索ODBC，打開ODBC 32，點擊驅動選項卡，滾動到您使用的連接類型的驅動，日期列在最右邊。）

Answer 7

類似luca.vercelli提供的解決方案：在R，使用dbConnect從odbc package，可以指定數據庫使用的encoding 。 我的數據庫使用SQL_Latin1_General_CP1_CI_AS排序規則，在dbConnect中指定latin1編碼解決了這個問題。