resultset.getString(Long Varchar字段)乱码

[realcbb]

数据库: db2
用con.prepareStatement(sql, ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE)的话,取出来的long varchar 类型字段是乱码;

如果用con.prepareStatement(sql), 取出来就是正确的.

请问有没有谁碰到过这个问题, 指教一下.

[kernll]

如果是这样，那么你的操作系统和你的数据库的默认的字符编码是不同的。或者说你用的框架有的方法是没有是使用字符编码来进行校验的。所以重载的方法也可能实现的检验方式是不同的。小小浅见。。。

[crazylaa]

[Quote=引用楼主 realcbb 的回复:]
数据库: db2
用con.prepareStatement(sql, ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE)的话,取出来的long varchar 类型字段是乱码;

如果用con.prepareStatement(sql), 取出来就是正确的.

请问有没有谁碰到过这个问题, 指教一下.
[/Quote]

这这这。。。加了两个参数应该不会对编码有影响啊。。。难道IBM又捣鬼了？？？

第一个参数指定 ResultSet 的类型。其选项有：

TYPE_FORWARD_ONLY：缺省类型。只允许向前访问一次，并且不会受到其他用户对该数据库所作更改的影响。
TYPE_SCROLL_INSENSITIVE：允许在列表中向前或向后移动，甚至可以进行特定定位，例如移至列表中的第四个记录或者从当前位置向后移动两个记录。不会受到其他用户对该数据库所作更改的影响。
TYPE_SCROLL_SENSITIVE：象 TYPE_SCROLL_INSENSITIVE 一样，允许在记录中定位。这种类型受到其他用户所作更改的影响。如果用户在执行完查询之后删除一个记录，那个记录将从 ResultSet 中消失。类似的，对数据值的更改也将反映在 ResultSet 中。


第二个参数设置 ResultSet 的并发性，该参数确定是否可以更新 ResultSet。其选项有：

CONCUR_READ_ONLY：这是缺省值，指定不可以更新 ResultSet
CONCUR_UPDATABLE：指定可以更新 ResultSet

[realcbb]

但的确是这样的,其他什么都没改,所以很奇怪...

[realcbb]

最新测试, 把ResultSet.TYPE_SCROLL_SENSITIVE换成TYPE_FORWARD_ONLY就不会出现乱码.
请教大家!

[crazylaa]

[Quote=引用 4 楼 realcbb 的回复:]
最新测试, 把ResultSet.TYPE_SCROLL_SENSITIVE换成TYPE_FORWARD_ONLY就不会出现乱码.
请教大家!
[/Quote]
sensitive，数据库的更改会影响当前结果集且游标可以来回定位。。。。forward_only不会，且只能前滚。
是否数据库的更改影响了结果集的metadata？
楼主改为TYPE_SCROLL_INSENSITIVE看看有没有乱码？如果没有乱码就表明数据库更改导致结果集MetaData有更改，可能是DB2的一个bug。。

[realcbb]

[Quote=引用 5 楼 crazylaa 的回复:]
引用 4 楼 realcbb 的回复:
最新测试, 把ResultSet.TYPE_SCROLL_SENSITIVE换成TYPE_FORWARD_ONLY就不会出现乱码.
请教大家!

sensitive，数据库的更改会影响当前结果集且游标可以来回定位。。。。forward_only不会，且只能前滚。
是否数据库的更改影响了结果集的metadata？
楼主改为TYPE_SCROLL_INSENSITIVE看看有没有乱码？如果没有乱码就表明数据库更改导致结果集MetaData有更改，可能是DB2的一个bug。。
[/Quote]

TYPE_SCROLL_INSENSITIVE也是乱码, 与CONCUR是否可以并发更新没有关系.
只要不是TYPE_FORWARD_ONLY就是乱码...但只是LONG VARCHAR字段是乱码, 普通的VARCHAR还是正确的.


ps: 另外我很奇怪的是, 数据库的编码是GBK, 配置weblogic连接池和数据源的时候都没有设置数据库编码的地方, 这样取出来的数据居然不需要转码. 难道不指定数据库的编码就是按照系统默认编码来算?

[liuahuilele]

db2不懂 所以顶好了

[crazylaa]

[Quote=引用 6 楼 realcbb 的回复:]
引用 5 楼 crazylaa 的回复:
引用 4 楼 realcbb 的回复:
最新测试, 把ResultSet.TYPE_SCROLL_SENSITIVE换成TYPE_FORWARD_ONLY就不会出现乱码.
请教大家!

sensitive，数据库的更改会影响当前结果集且游标可以来回定位。。。。forward_only不会，且只能前滚。
是否数据库的更改影响了结果集的metadata？
楼主改为TYPE_SCROLL_INSENSITIVE看看有没有乱码？如果没有乱码就表明数据库更改导致结果集MetaData有更改，可能是DB2的一个bug。。


TYPE_SCROLL_INSENSITIVE也是乱码, 与CONCUR是否可以并发更新没有关系.
只要不是TYPE_FORWARD_ONLY就是乱码...但只是LONG VARCHAR字段是乱码, 普通的VARCHAR还是正确的.


ps: 另外我很奇怪的是, 数据库的编码是GBK, 配置weblogic连接池和数据源的时候都没有设置数据库编码的地方, 这样取出来的数据居然不需要转码. 难道不指定数据库的编码就是按照系统默认编码来算?
[/Quote]

那就是只要游标滚动，LONG VARCHAR就会乱？奇怪之至，打IBM的800电话去问下，db2的Long Varchar是否对汉字进行了特殊处理还是怎么的。。

ps:连进DB2/Oracle等数据库不需要像mysql、postgres一样指定编码的，它会以数据库的编码方式返回数据给你。

[realcbb]

[Quote=引用 8 楼 crazylaa 的回复:]
引用 6 楼 realcbb 的回复:
引用 5 楼 crazylaa 的回复:
引用 4 楼 realcbb 的回复:
最新测试, 把ResultSet.TYPE_SCROLL_SENSITIVE换成TYPE_FORWARD_ONLY就不会出现乱码.
请教大家!

sensitive，数据库的更改会影响当前结果集且游标可以来回定位。。。。forward_only不会，且只能前滚。
是否数据库的更改影响了结果集的metadata？
楼主改为TYPE_SCROLL_INSENSITIVE看看有没有乱码？如果没有乱码就表明数据库更改导致结果集MetaData有更改，可能是DB2的一个bug。。


TYPE_SCROLL_INSENSITIVE也是乱码, 与CONCUR是否可以并发更新没有关系.
只要不是TYPE_FORWARD_ONLY就是乱码...但只是LONG VARCHAR字段是乱码, 普通的VARCHAR还是正确的.


ps: 另外我很奇怪的是, 数据库的编码是GBK, 配置weblogic连接池和数据源的时候都没有设置数据库编码的地方, 这样取出来的数据居然不需要转码. 难道不指定数据库的编码就是按照系统默认编码来算?


那就是只要游标滚动，LONG VARCHAR就会乱？奇怪之至，打IBM的800电话去问下，db2的Long Varchar是否对汉字进行了特殊处理还是怎么的。。

ps:连进DB2/Oracle等数据库不需要像mysql、postgres一样指定编码的，它会以数据库的编码方式返回数据给你。
[/Quote]


IBM 800电话是什么? 8008101818?
可是如果数据库编码是UTF-8, 而我在查询sql中有where中文条件, 它也能识别吗? 还是需要我在构造sql的时候进行转码?