jFresH_MaN(ＴＭ)，请教你个问题。我问过很多论坛了都没有人能够解决

[zmt_cn]

请教个问题，我问过很多论坛了都没有人能够解决，点名问你是因为看你在CSDN上活跃程度很高，并且级别也很高。希望你能够帮我解决。
你一定也遇到过这样的情况：当数据库记录集中存在不可读字符被select出来后，在resultSet.next()到那条数据时会报错（违反协议），之后resultSet不可用，使用try也无法跳过异常。当然如果可以把这些不可读字符重新写入这个问题将不会再出现，可问题是1、数据库中数据量很大（几百万条），存在不可读字符的记录也很多，我无法一一重写。2、这个数据库对于我的程序来说是只读的，每次要更改记录需要找数据库管理员去该。所以我想，能否在程序中跳过这条异常数据而使程序能够继续运行？
我不知道JDBC为什么会有这种低级错误，这些不可读字符记录在PL/SQL中都能够被读出来，虽然他们仍然无法正常显示中文。
不要叫我更改数据库的字符集，因为数据库对我来说是只读的，并且大的改动数据库管理员也不敢乱动。
无论如何，先谢了！

[jFresH_MaN]

通过查询ORACLE资料，证明这是一个ORACLE　JDBC　DRIVER的BUG

[zmt_cn]

可是，我查的没有BLOB字段阿，并且，我不使用THIN的驱动而使用WEBLOGIC的驱动也一样会报这个错误啊！

[zmt_cn]

是啊，我一直都认为这是JDBC的BUG，哎，但无论如何，这个问题已经延续很长时间了，难道他们就不知道及时弥补吗？郁闷

[jFresH_MaN]

是的！刚才我在bea的中文开发论坛也看到同样的问题
也就是说他的驱动同样是有问题的

我现在不能上国外网，你可以用
jdbc oracle protocol violation
关键字再搜索一下，应该有收获的

我觉得是驱动的bug吧。。
你可以升级一下驱动试试

[zmt_cn]

我所知道各种驱动都试过了,不过ODBC到是没有试过,明天到公司再试试,呵呵
谢谢你了阿

[jFresH_MaN]

不一定换驱动就有用
我看刚才搜到的信息是说oracle8i和9i的部分数据库驱动都有这个bug啊
你可以试试高版本的数据库和驱动

[zmt_cn]

9i我到是没有遇到过,我现在的程序是做一个数据仓库,我的数据库是9i的,被我采集数据的数据库是8i的,郁闷阿,一旦遇到这种数据,我整个的计划任务都被它中断了,更要命的是这种数据特别多

[jFresH_MaN]

如果真是驱动的bug，那我们谁也没办法
：（

[zmt_cn]

但是为什么有些数据在我程序里报错，在PL/SQL里却能够读呢！然道PL/SQL不是使用JDBC驱动吗？

[jFresH_MaN]

PL/SQL我不是很了解，呵呵

其实我没用过oracle，因为我的机器不能装oracle呵呵

[zmt_cn]

哦，这样啊，呵呵
无论如何，还是谢谢你了

[umbrella1984]

你是读取某字段时出错还是一执行SELECT就出错了，如果是前者可能是你的字段类型与字段内容不匹配，比如长度什么的，另外你查查是哪个字段出的错，然后到数据库看看里面到底是什么值导致错误？

[zmt_cn]

是乱码
另外,这个问题困扰我差不多半年了,在操作代码阿什么的上,我不会犯低级错误的（要有也早就调试出来了）,所以简单的诸如字段类型阿什么的是绝对没有问题的。

[zmt_cn]

select能够成功，并且可以rs.next()，只是遍历到有“特定某个”乱码的时候，在执行rs.next()这条语句的时候报错。报错后进程死亡。无法捕捉异常。

[zmt_cn]

up

[zmt_cn]

to ll42002(灰舌)
我建议你使用与数据库相符的驱动程序试试。
----------

我只有是能够用的数据库驱动我都用过了，结果都是一样：The connection is dead.
可问题是：我不能让它死亡，因为我做的是计划任务数据采集，一旦连接死亡，整个计划任务都会被异常带着死亡。

看上面的那段英文，那就是除了该数据库记录外，就没有别的方法了？
那为什么PL/SQL能够做到呢（PL/SQL能够读出某些让我的连接死亡的数据记录。）？
有谁知道吗？

[zmt_cn]

to wcmj(望尘莫及)
我想问下出现乱码的字段是什么类型的 char? varchar?....
-----------

全部是 varchar 类型

[jFresH_MaN]

还没解决啊？
你换驱动和数据库版本试了没有？
如果高版本没有问题就可以肯定是bug了

[ll42002]

看看下面这段：
The Thin driver throws this exception when it reads something from the RDBMS that it did not expect. This means that the protocol engine in the Thin driver and the protocol engine in the RDBMS are out of synch. There is no way to recover from this error. The connection is dead. You should try to close it, but that will probably fail too.
If you get a reproducible test case that generates this error, please file a TAR with Oracle Global Support. Be sure to specify the exact version numbers of the JDBC driver and the RDBMS, including any patches.
我觉得是数据库引擎对某条记录的处理方式和JDBC驱动程序对某条记录的处理方式不一致，而产生的错误。我建议你使用与数据库相符的驱动程序试试。

[wcmj]

我想问下出现乱码的字段是什么类型的 char? varchar?....