resultset.getString(Long Varchar字段)乱码

数据库: db2
用con.prepareStatement(sql, ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE)的话,取出来的long varchar 类型字段是乱码;如果用con.prepareStatement(sql), 取出来就是正确的.请问有没有谁碰到过这个问题, 指教一下.

解决方案 »

  1.   


    这这这加了两个参数应该不会对编码有影响啊难道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 
      

  2.   

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

  3.   

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

  4.   


    TYPE_SCROLL_INSENSITIVE也是乱码, 与CONCUR是否可以并发更新没有关系.
    只要不是TYPE_FORWARD_ONLY就是乱码...但只是LONG VARCHAR字段是乱码, 普通的VARCHAR还是正确的.
    ps: 另外我很奇怪的是, 数据库的编码是GBK, 配置weblogic连接池和数据源的时候都没有设置数据库编码的地方, 这样取出来的数据居然不需要转码. 难道不指定数据库的编码就是按照系统默认编码来算?