oracle ORA-01704问题(clob字段insert报错)

今天遇到一个特殊情况,由于项目新增了防xss攻击的filter(使用antisamy),导致前台的富文本编辑框不能正确保存,html格式被过滤处理,保存后的数据无法被前台正确渲染从而导致显示乱码问题。为了临时解决问题,用户要求我把富文本数据手动刷进数据库。
这也不是一件复杂的事情,首先把filter关掉,然后正常操作,之后导出正确保存的数据,把数据导入产线环境就可以了。前台页面在读取数据的时候并不会调用filter,所以显示不会有问题。
但实际做insert操作的时候,sql报错:

ORA-01704: string literal too long

看到这个报错首先一拍脑袋,又在简单的地方踩坑了。oralce在处理sql的时候,会把传入的字符串转化为varchar2处理,varchar2的最大长度是4000,如果insert语句中单个字符串的长度超过4000,那就肯定会报错。也怪我太久没处理过clob字段数据,把这事儿给忘了。
解决这个问题也并不复杂,有两种比较简单的方式:一种是拼接字符串;一种是绑定变量。
拼接字符串的处理非常的简单粗暴,就是把超长的字符串切分成若干个长度不超过4000的子串,逐个update进去。比如这么写:

update usertable set name='abcdefg' where userId = 'aaa';
update usertable set name = name||'hijklmn' where userId = 'aaa';

这样子只要每一次拼接进去的字符串长度不超过4000,就不会报错,非常的简单。但是如果字符串的长度达到5位数,那显然实际操作起来就太麻烦。这时候就要采取第二种办法,绑定变量。
绑定变量也不复杂,就是把要插入的字符串先绑定给一个变量,然后在insert或者update语句中用变量代替实际字符串执行,就不会报错。写法如下:

declare
cntent clob :='abcdefg';
begin
    insert into table usertable values('aaa',content);
    end

富文本字段实在是太长了,于是我选择了第二种写法,数据就能正常插入了。

### DBeaver 中解决 ORA-01704 字符串长度限制的方案 ORA-01704 错误通常发生在 Oracle 数据库尝试将超过 4000 字节的字符串插入到 `VARCHAR2` 列时。此问题的根本原因是 Oracle 默认将字符串作为 `VARCHAR2` 类型处理,而该类型的单个值最大长度为 4000 字节[^1]。 #### 方案一:使用 CLOB 替代 VARCHAR2 如果目标列的数据类型允许存储更大的文本量,则可以考虑将其改为 `CLOB` 类型。以下是具体操作方法: 1. 修改表结构以支持 `CLOB`: ```sql ALTER TABLE your_table MODIFY (your_column CLOB); ``` 2. 插入超长字符串时,可以直接指定为目标列为 `CLOB` 类型: ```sql INSERT INTO your_table (id, long_text) VALUES (1, TO_CLOB('Your very long string here...')); ``` 通过上述方式,能够有效规避因字符串长度超出限制而导致的 ORA-01704 错误[^3]。 --- #### 方案二:声明临时变量并分步执行 当无法更改数据库模式或需要兼容现有脚本时,可以通过 PL/SQL 块实现数据插入。这种方法适用于手动编写 SQL 脚本的情况。 示例代码如下: ```plsql DECLARE aaa CLOB := 'XXXX超长的文本'; BEGIN -- 删除旧记录(可选) DELETE FROM your_table WHERE id = 1; -- 插入新记录 INSERT INTO your_table (id, long_text) VALUES (1, aaa); END; / ``` 这种方式先将超长字符串赋给一个 `CLOB` 变量,再利用该变量完成插入操作,从而绕过了直接插入带来的长度限制。 --- #### 方案三:调整 JDBC 驱动行为 对于基于工具(如 DBeaver)的操作场景,有时可通过配置 JDBC 参数优化性能。例如,在连接 URL 中加入以下参数可能会有所帮助: ```plaintext ?oracle.jdbc.JDBCType=CHAR&useServerPrepStmts=false ``` 这些选项强制驱动程序按照字符而非字节数计算长度,并禁用服务器端预编译语句缓存机制,有助于减少潜在冲突[^2]。 注意:实际效果取决于所使用的驱动版本以及环境特性,请谨慎测试后再推广至生产环境中应用。 --- ### 结论 针对不同业务需求和技术背景可以选择合适的解决方案。若频繁涉及大量文本数据处理建议优先采用 **方案一** 改变字段定义;而对于一次性任务或者已有固定流程则推荐运用 **方案二** 的动态块逻辑;最后还可以探索是否适合引入特定于客户端层面的技术手段即 **方案三** 来缓解部分压力。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值