为ZIP_CODE提供得参数（尺子）大于ZIP_CODE得列宽，或者为CITY提供得参数（尺子）大于CITY得列宽.
了解为两个?占位符提供的值会很有趣。

这是mssql ODBC驱动程序的已知问题。根据Microsoft博客文章：
SQLBindParameter的ColumnSize参数指的是SQL类型中的字符数，而BufferLength是应用程序缓冲区中的字节数。（n）或字符（n），应用程序绑定参数为SQL_C_CHAR或SQL_C_VARCHAR，客户端的字符编码为UTF-8，可能会得到一个“String data，右截断”错误，即使ColumnSize的值与服务器上数据类型的大小对齐也是如此。发生此错误的原因是字符编码之间的转换可能会更改数据的长度。例如，右撇号字符（U+2019）在CP-1252中编码为单字节0x 92，但在UTF-8中编码为3字节序列0xe 2 0x 80 0x 99。
您可以找到完整的文章here。

我通过在“？"上使用convert来解决这个问题，所以我的代码看起来像convert（char（50），？），这样就消除了截断错误。

我也遇到了同样的问题。所以，我创建了一个存储过程，并定义了大小，如@FromDate日期时间，@ToDate日期时间，@BL varchar（50）
在@BL varchar（50）中定义了大小后，我没有遇到任何问题。现在它工作得很好

如果连接是通过PHP完成的，我们用连接参数“CharacterSet”来解决：

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

我今天在一个已经运行了很多年的应用程序上体验到了这一点。我的事业有点不同，所以我想我会分享给将来遇到这种情况的人。
对于我遇到的问题，我们有一个运行在客户端机器上的应用程序，客户端通过ODBC连接与DB服务器进行通信。无论出于什么原因，客户端上的ODBC驱动程序更新到了比服务器更新的版本，（这在过去通常不重要）。版本只相隔1个月，但却是问题的原因。我去了windows补丁历史记录，卸载了日期与ODBC驱动程序日期最匹配的补丁，这样就解决了问题。（要检查ODBC驱动程序版本，只需在windows开始中搜索ODBC，打开ODBC 32，单击驱动程序选项卡，滚动到您使用的连接类型的驱动程序，日期会在最右边列出。）