2015-12-17 2 views
0

exécutant la commande suivante dans SQL Developer:Oracle "ORA-00932: types de données incompatibles: nombre attendu se TIMESTAMP" sur INSERT INTO mais pas SELECT

insert into table2 
select * 
from table1 
where id_ in (select fileid 
       from table3 
       where status in ('DELETED', 'TODELETE') 
       and softdeletedate < to_date('11/08/2015 01:00:00 AM', 'mm/dd/yyyy hh:mi:ss AM')) 
and id_ not in (select id_ from table2); 

résultats dans cette erreur:

ORA-00932: inconsistent datatypes: expected NUMBER got TIMESTAMP

Si je supprime la première partie (insert into table2), la commande select s'exécute correctement et, comme prévu, ne renvoie aucun enregistrement.

Les tables1 et table2 ont plus de 70 colonnes de VARCHAR2, TIMESTAMP et NUMBER.

Les tables1 et table2 sont créées par une application qui parcourt les colonnes table1 et crée table2, la seule différence étant que table1 a plusieurs index alors que table2 a un seul index.

J'ai vérifié que table1 et table2 ont les mêmes colonnes et types de données. Cependant, la sortie de "desc table1" et "desc table2" répertorie les colonnes dans un ordre différent, mais elles correspondent toutes.

Lorsque j'exécute la commande sur d'autres tables qui ont été créées de la même manière mais qui ont moins de colonnes (elles ont toujours les mêmes types de colonnes), l'insertion fonctionne et n'affiche aucune erreur. L'exécution de la commande "desc" sur ces tables répertorie les colonnes dans le même ordre.

J'ai effectué plusieurs recherches Google pour trouver l'erreur, mais je n'ai pas trouvé de réponse. Ma version Oracle est 11g.

Une idée pourquoi cette erreur est retournée et comment la contourner?

Répondre

1

Vous dites que vos deux tables ont les mêmes colonnes, mais pas dans le même ordre - cela est très susceptible d'être la cause de votre problème car, si vous ne spécifiez pas les colonnes vous-même, vous comptez sur l'ordre de colonne par défaut (par exemple, la première colonne de table1 correspondra à la première colonne de table2, etc.). Si vos commandes de colonnes dans les deux tableaux ne correspondent pas, ne soyez pas surpris lorsque vous rencontrez des problèmes tels que des types de données incompatibles!

Si j'étais vous, j'indiquerais explicitement les colonnes sélectionnées et insérées, plutôt que de me fier à l'ordre des colonnes par défaut.

Ainsi, il devrait ressembler à:

insert into table2 (id_, 
        other_col_1, 
        other_col_2, 
        ...) 
select id_, 
     other_col_1, 
     other_col_2, 
     ... 
from table1 
where id_ in (select fileid 
       from table3 
       where status in ('DELETED', 'TODELETE') 
       and softdeletedate < to_date('11/08/2015 01:00:00 AM', 'mm/dd/yyyy hh:mi:ss AM')) 
and id_ not in (select id_ from table2); 
+1

Je voudrais aller plus loin que même simplement * * suggérant des noms de colonnes explicites. Chaque fois que vous: a) vous souciez de l'ordre des colonnes, et b) utilisez 'select * from ...' pour récupérer les colonnes dans un ordre implicite - c'est un bug qui n'attend que de se produire. Cela pourrait ne pas vous mordre aujourd'hui, ou même pas du tout, mais c'est très fragile et une mauvaise idée. – Gerrat

+0

Merci à vous deux pour la réponse rapide. La spécification des colonnes prend explicitement en charge le problème. – user3722575