SQL2005中出现的怪现象，是Bug 还是啥情况？

[kangss]

将长度为20的一个字符串保存到SQL2005对应的varchar字段里，VFP读取过来之后该字符串的值被SQL2005“私自改变”了。

m._字符=CHR(174)+CHR(137)+CHR(163)+CHR(122)+CHR(111)+CHR(151)+CHR(136)+CHR(145)+CHR(98)+CHR(100)+;
CHR(191)+CHR(125)+CHR(174)+CHR(137)+CHR(163)+CHR(122)+CHR(111)+CHR(151)+CHR(201)+CHR(228)
长度=20
将m._字符保存到DBF文件的C(20)字段中正常，保存到SQL2000的varchar(20)字段也正常。


把SQL2000下的这个正常的数据库附加到SQL2005之后：这个字段内容就“不能”修改了，一旦修改SQL2005就有可能会修改它。



试验一：m._字符不变直接更新到SQL2005对应字段中
m._字符=CHR(174)+CHR(137)+CHR(163)+CHR(122)+CHR(111)+CHR(151)+CHR(136)+CHR(145)+CHR(98)+CHR(100)+;
CHR(191)+CHR(125)+CHR(174)+CHR(137)+CHR(163)+CHR(122)+CHR(111)+CHR(151)+CHR(201)+CHR(228)
在VFP中读取该字段的值发现：最后一个字符的ASC值被SQL2008修改成了32。
经过测试发现：最后一个字符ASC大于等于129，SQL2005就会把它变成32

但也不是所有最后一位ASC是228的就一定会被改变成32。

试验二：20个字符的ASC都是228，保存到SQL2005，读取出来正常。
_字符=CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+;

CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)



试验三：将倒数第4个字符的ASC改成111，保存到SQL2005，读取出来之后，最后一个字符的ASC变成了32。

_字符=CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+;
CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(228)+CHR(111)+CHR(228)+CHR(228)+CHR(228)


这个现象不是网上说的中文字符保存到SQL2005中，读取之后看到的是乱码，用修改排序规则的方法解决。

SQL2005为啥有时候会把最后一个字符修改呢？

[都市夜猫]

记得以前看过有关字符串在客户端与 sql server 后端之间传递时，odbc 驱动程序会先自动转换成 unicode。
可能是这个原因，导致你的字符串在转换时，出现了因存在无效字符而丢失的情况。
通常来说，要存储在 varchar 类型中的字符串，应该是在你的本机页码中可识别的字符串，否则，应该用 varbinary 类型来存储

用 vfp 的 strconv 函数可以部分证明这种情况：
cc = CHR(174)+CHR(137)+CHR(163)+CHR(122)+CHR(111)+CHR(151)+CHR(136)+CHR(145)+CHR(98)+CHR(100)+;
CHR(191)+CHR(125)+CHR(174)+CHR(137)+CHR(163)+CHR(122)+CHR(111)+CHR(151)+CHR(201)+CHR(228)
c1 = strconv(cc, 5)
c2 = strconv(c1, 6)
此时 c1 <> c2，如果全部 chr(228)，则 c1 == c2

[kangss]

引用 2 楼 dkfdtf 的回复:

看看这篇文章，似乎能说明某些原因： http://support2.microsoft.com/kb/234748/zh-cn

谢谢！应该是这篇文章中叙述的情况。 今天测试又发现了新的情况： 测试一：直接安装SQL2005不打SP4补丁 将字符串后面加一个空格：m._字符 = m._字符 +chr(32) 提交保存到数据库中没有发生“截断二进制...数据丢失”的提示，VFP读取之后正确。字符串没有被修改。 测试二：打SP4补丁 m._字符后面加与不加chr(32)，提交保存到数据库之后，VFP读取出来的字符串还是被修改了。 经过strconv(cc, 5)转换之后，字符宽度增加了。

[kangss]

引用 1 楼 dkfdtf 的回复:

记得以前看过有关字符串在客户端与 sql server 后端之间传递时，odbc 驱动程序会先自动转换成 unicode。 可能是这个原因，导致你的字符串在转换时，出现了因存在无效字符而丢失的情况。 通常来说，要存储在 varchar 类型中的字符串，应该是在你的本机页码中可识别的字符串，否则，应该用 varbinary 类型来存储 用 vfp 的 strconv 函数可以部分证明这种情况： cc = CHR(174)+CHR(137)+CHR(163)+CHR(122)+CHR(111)+CHR(151)+CHR(136)+CHR(145)+CHR(98)+CHR(100)+; CHR(191)+CHR(125)+CHR(174)+CHR(137)+CHR(163)+CHR(122)+CHR(111)+CHR(151)+CHR(201)+CHR(228) c1 = strconv(cc, 5) c2 = strconv(c1, 6) 此时 c1 <> c2，如果全部 chr(228)，则 c1 == c2

感谢夜侠“应该用 varbinary 类型来存储”搞定。

[kangss]

varbinary 在VFP里面是“备注（二进制）”类型

[都市夜猫]

看看这篇文章，似乎能说明某些原因： http://support2.microsoft.com/kb/234748/zh-cn