Oracle 中的数据类型不一致
我有以下功能:
create or replace
FUNCTION "MXUPGKEYVAL"(tbname varchar2,colname varchar2) return number is
val number;
BEGIN
EXECUTE IMMEDIATE
'select sum(length('||colname||')) from '||tbname into val;
return val;
END;
和以下更新:
update ANINTEGDATA set val1=to_char(nvl(MXUPGKEYVAL(MX5T,MX5C),0)) where type=1;
当我执行更新时,我得到:
ORA-00932: inconsistent datatypes: expected NUMBER got LONG
ORA-06512: at "MAXIMO.MXUPGKEYVAL", line 6
ORA-06512: at line 2
知道为什么会发生这种情况吗?
问候, 拉杜。
稍后编辑:
表 ANINTEGDATA 为:
create table ANINTEGDATA
(
MX5T VARCHAR2(50),
MX5C VARCHAR2(50),
MX6T VARCHAR2(50),
MX6C VARCHAR2(50),
TYPE NUMBER,
VAL1 VARCHAR2(200),
VAL2 VARCHAR2(200)
);
i have the following function:
create or replace
FUNCTION "MXUPGKEYVAL"(tbname varchar2,colname varchar2) return number is
val number;
BEGIN
EXECUTE IMMEDIATE
'select sum(length('||colname||')) from '||tbname into val;
return val;
END;
and the following update:
update ANINTEGDATA set val1=to_char(nvl(MXUPGKEYVAL(MX5T,MX5C),0)) where type=1;
when i execute the update i get:
ORA-00932: inconsistent datatypes: expected NUMBER got LONG
ORA-06512: at "MAXIMO.MXUPGKEYVAL", line 6
ORA-06512: at line 2
any idea why that happens?
Regards,
Radu.
Later edit:
table ANINTEGDATA is:
create table ANINTEGDATA
(
MX5T VARCHAR2(50),
MX5C VARCHAR2(50),
MX6T VARCHAR2(50),
MX6C VARCHAR2(50),
TYPE NUMBER,
VAL1 VARCHAR2(200),
VAL2 VARCHAR2(200)
);
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
你的功能有效。
此外,它在您的更新声明中起作用。
当相关列具有 LONG 数据类型时,它不起作用。错误消息并不那么清楚,但已经足够清楚了。
这也是为什么Teh Suck 很长的另一个原因!早就应该被废除了。当您正在进行数据迁移练习时,现在是考虑迁移到非常灵活的 CLOB 数据类型的好时机。
无论哪种方式,您都需要一个约定来指示目标列包含大量数据。
如果您确实需要知道 LONG 数据量的精确范围,我建议您将 LONG 卸载到 CLOB 列并对它们求和。
Your function works.
Furthermore it works in your update statement.
Where it doesn't work is when the column in question has the LONG datatype. The error message isn't as clear as it could be but is clear enough.
This is just another reason why LONG is Teh Suck! and should have been done away with a long time ago. As you're doing a data migration exercise now would be a good time to consider moving to the oh-so flexible CLOB data type.
Either way you need a convention to indicate that the target column contains a shedload of data.
If you really need to know the precise extent of the LONG data volumes I suggest you unload the LONGs to CLOB columns and sum those instead.