2010-08-18 12 views
1

i ont la fonction suivante:types de données inconsistantes dans 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; 

et la mise à jour suivante:

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

quand j'exécute la mise à jour i get:

ORA-00932: inconsistent datatypes: expected NUMBER got LONG 
ORA-06512: at "MAXIMO.MXUPGKEYVAL", line 6 
ORA-06512: at line 2 

toute idée pourquoi Cela arrive?

Cordialement, Radu.

modifier plus tard:

Table ANINTEGDATA est:

create table ANINTEGDATA 
(
    MX5T VARCHAR2(50), 
    MX5C VARCHAR2(50), 
    MX6T VARCHAR2(50), 
    MX6C VARCHAR2(50), 
    TYPE NUMBER, 
    VAL1 VARCHAR2(200), 
    VAL2 VARCHAR2(200) 
); 
+0

Salut Radu, nous ne pouvons pas vous donner une réponse correcte si vous ne nous donnez pas de données d'échantillon et les types de données de colonne de cette table: 'ANINTEGDATA (val1, type, MX5T, MX5C)'. –

+0

Bonjour Vincent. Merci pour votre réponse. J'ai ajouté les types de données de la table ANINTEGDATA. la table contient des valeurs pour MX5T, MX5C et les champs de type maintenant. Les champs MX5T et MX5C contiennent les noms de tables et les noms de colonnes de différentes tables sur le même schéma. –

+0

Le premier argument de MXUPGKEYVAL est apparemment supposé être un nom de table, et dans l'exemple cet argument est donné comme 'MX5T' (je crois que ceci devrait être entre guillemets). Y a-t-il une table MX5T? C'est aussi un nom de colonne sur ANINTEGDATA. S'il y a une table MX5T, pourriez-vous poster la définition de cette table? Si ce n'est pas le cas, vérifiez que la définition de la fonction ci-dessus est à jour. J'ai créé la table ANINTEGDATA et la fonction MXUPGKEYVAL comme indiqué ci-dessus mais j'ai obtenu des erreurs différentes de celles que vous avez reçues. Merci. –

Répondre

6

Votre fonction fonctionne.

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

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

SQL> 

De plus, cela fonctionne dans votre instruction de mise à jour.

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

1 row updated. 

SQL> 

Lorsque cela ne fonctionne pas est lorsque la colonne en question a le type de données LONG. Le message d'erreur n'est pas aussi clair qu'il pourrait l'être mais est assez clair.

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> 

Ceci est juste une autre raison pour laquelle LONG est Teh Suck! et aurait dû être supprimé il y a longtemps. Comme vous faites un exercice de migration de données maintenant serait un bon moment pour envisager de passer au type de données CLOB oh-si flexible. Dans les deux cas, vous avez besoin d'une convention pour indiquer que la colonne cible contient une distribution de données.

Si vous avez vraiment besoin de connaître l'étendue exacte des volumes de données LONG, je vous suggère de décharger les colonnes LONGs à CLOB et de les additionner.

+0

Merci pour votre réponse. Sur le nouvel environnement, nous avons déjà un type de données clob. Cordialement, Radu. –

+0

@RaduDragomir - C'est bon. Nous pouvons utiliser les CLOB à peu près comme n'importe quelle autre colonne. Ils sont beaucoup moins tracassiers que LONGs. – APC