Bonjour,

Si y a un bon expert ici :

Contexte : recuperer dans une table tous les contrats ne se trouvant pas dans une autre

La premiere me revoint des résultats, la deuxieme rien du tout.
Les deux sont du varchar2(15)

Si quelqu'un voit le truc

chelou
 
ceci dit, moi j'utiliserais plutôt : (plus standard que les deux tiennes, et fonctionnel sur n'importe quel sgbd y compris les plus pourris)

SELECT a.id_prosp_unique
FROM tapvcontrat a
LEFT OUTER JOIN tapecontrat b ON b.id_prosp_unique = a.id_prosp_unique
WHERE b.id_pros_unique IS NULL

sinon, teste ta seconde avec un not exists plutôt.
j'ai l'impression (et ça conforte mon hostilité) que le "not in" marche quand il veut et comme il veut, sous oracle du moins)
 

SELECT a.id_post_unique
FROM tapvcontrat a
WHERE NOT EXISTS (SELECT NULL FROM tapecontrat b ON b.id_post_unique = a.id_post_unique)

en tout cas, pour moi t'as mis le doigt sur un des nombreux bugs d'Oracle.

Ah oui tiens j'ai oublié de mettre à jour ici.
Effectivement j'ai testé avec un NOT EXISTS et ca marche parfaitement.

Et ta jointure externe aussi marche très bien.

J'irais bien dire deux mots à Oracle moi

On peut faire un voyage groupé si tu veux

gardez moi une place de choix svp

c'est vrai que c'est un gros bébés capricieux mais y a souvent moyen de comprendre le pourquoi du comment du résultat bizarre.
tu peux afficher tes clés qui remontent normalement avec la 1ere requete?

Je n'ai pas très bien compris ta question, alors je te donne l'EXPLAIN PLAN, c'est peut etre ca que tu veux
 

 
Ouch le cout

c'est une grosse merde bloatée et totalement imprévisible ouais

perso je n'ai pas vraiment de soucis avec, tout mon dataware house est en oracle, mais bon ce n'est pas comparable a un vrai système de prod vu que mes users ne font que des select (ca c'est le pied) et que je contrôle les mise a jour etc, mais au niveau traitement j'ai rarement des surprises.
 
je pensais plutot au foirage du in a cause de x centaines de millier de key comme membres, je n'ai pas l'habitude de lire les explain plain en text (toad noob), le 2ème chiffre derriere la ligne ressort le résultat  en Kbytes non? parceque ca fait pas mal de varchar(15) ca, bon c'est pas une excuse pour qu'il foire on est bien d'accord
 
 
tiens quand tu disais qu'il ne te renvoyait rien du tout, tu parlais bien d'un "0 row returned"?

je pense aussi que c'est le in qui déconne. (c'est même sûr, c'est pas pour rien qu'Oracle déconseille son utilisation)
 
ceci dit, il devrait au contraire retourner plus de lignes que prévu du coup, alors que là il en ramène pas assez

Ouais 0 row, et oui il explose les compteurs le not in
5000 records 536 KBytes mais ca j'ai du mal à dechiffrer pour un plan d'execution ce que ca signifie concretement

Ca signifie concrètement qu'autant pour certaines fonctionalités, Oracle est extrêment bon, autant pour d'autres, elles ont été développées en QBasic par des stagiaires qui se sont tirés sans écrire de doc, et que plus personne s'ose mettre la main dedans pour corriger les bugs.
 
En gros, Oracle est un des moteurs de base de données les plus puissants, mais avec des limitations qui dépassent celles d'Access 2.0 (je suis pas sûr que j'exagère tant que ça...)

une grosse merde quoi... tiens, un truc qui m'arrive régulièrement :
 

lolilol non ? et je fais quoi pour résoudre ça ? je reboote le serveur et hop, tout remarche ! même David Copperfield il arrive pas à le faire ça !
en résumé : Copperfield arrive peut être à faire disparaitre un éléphant, mais Oracle arrive à éjecter son sysdba, c'est top

ca se tient comme résonnement, quand je vois je ne l'utilise carrément jamais des que je dépasse +/- 10 membres, j'irai max jusqu'a 100 mais je me ferai mal je crois.
 
c'est pas comme ca sur tous les sgbd?

Pas compris ta remarque Casimimir

en gros je fais jamais de in sauf si je définis les valeurs litéralement, style in (1,2,3,4), mais très et de plus en plus rarement un sous select dedans, ou alors de nouveau un sous select qui ne va me ramener que très peu de membre et que j'en suis sur

D'autant qu'un IN est quasi toujours remplaçable par un EXISTS, qui fonctionne beaucoup mieux sous Oracle (pas de limitation du nombre de sous éléments)
 
Ceci dit, quand on a une solution plus propre sous la main, autant l'utiliser.