1

我有以下功能:

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)
);
4

1 回答 1

6

你的功能有效。

SQL> select mxupgkeyval('EMP', 'SAL') from dual
  2  /

MXUPGKEYVAL('EMP','SAL')
------------------------
                      78

SQL>

此外,它适用于您的更新语句。

SQL> update ANINTEGDATA set val1=to_char(nvl(MXUPGKEYVAL(MX5T,MX5C),0)) where type=1;

1 row updated.

SQL> 

当有问题的列具有 LONG 数据类型时,它不起作用。错误消息虽然不够清晰,但足够清晰。

SQL> alter table t34 add long_col long;

Table altered.

SQL> select mxupgkeyval('T34', 'LONG_COL') from dual
  2  /
select mxupgkeyval('T34', 'LONG_COL') from dual
       *
ERROR at line 1:
ORA-00932: inconsistent datatypes: expected NUMBER got LONG
ORA-06512: at "APC.MXUPGKEYVAL", line 6


SQL>

这只是 LONG 是 Teh Suck 的另一个原因!并且应该在很久以前就被取消了。当您正在进行数据迁移练习时,现在是考虑迁移到非常灵活的 CLOB 数据类型的好时机。

无论哪种方式,您都需要一个约定来指示目标列包含少量数据。

如果您真的需要知道 LONG 数据量的精确范围,我建议您将 LONG 卸载到 CLOB 列,然后将它们相加。

于 2010-08-18T10:49:08.410 回答