Bonjour,
 
Je suis sous oracle et j'ai une requête toute bête avec 3 jointures entre 4 tables mais j'ai un problème lorsque je mets le distinct :
 

 
Si j'enlève le distinct ça marche mais les doublons sont toujours présents.
 
Comment faire ?
 
Merci

1/ apprends à écrire une jointure
2/ peux-tu "réduire" ton problème: essayer sans certains champs et trouver la requête "minimum" qui présente le problème
3/ QUEL EST LE PROBL7ME PRODUIT PAR LE REQUETE AVEC LE DISTINCT??? /FOU /FOU

Les jointures sont bonnes, hormis le fait que je n'utilise pas des mots clés comme JOIN ou INNER JOIN, etc...
Le problème est que si j'ai un nombre de champs trop important dans le select il me met l'erreur :
 
ORA-01114 : IO error writing block to file 201 (block # 17447)
ORA-27072 : File I/O error
...
 
d'où ma question :
 
Est-ce qu'il y a un nombre maximum de champs à spécifier sous dans le select où il y a un distinct ?
 
Le plus fou c'est que si j'enlève les derniers champs à partir de tmp3.country ça marche.Ca marche de même si j'enlève le distinct et que je mets tous les champs.Mais quand je mets les deux ça ne marche pas.
 
Merci.
Je précise que j'éxecute cette requête sous PL/SQL developer.

Tes jointures sont certes bonnes mais cela doit faire environ 10 ans qu'on a arreté de les écrires comme ça. Quand tu postes sur un forum, si tu veux que ta question "touche" le plus grand nombre de personne, il est préférable d'utiliser l'écriture "standard d'aujourd'hui"

Quand à l'erreur ( c'est plus facile avec le code), je suis vraiment pas expert oracle mais un petit coup d'oeil sur la doc nous donne:

Donc je dirais que ta requête de la mort bourrine tellement le fichier temp que celui-ci dépasse sa taille max.
Je vérifierais donc la taille du-dit fichier sur le tablespace associé, voir la taille dispo sur le disque tout court.

ok j'ai fait des left join à la place. Mais cela me parait bizarre quand même qu'en rajoutant un distinct sur un champ il bourrine le fichier temp alors qu'en principe le distinct devrait ressortir moins de résultats et par conséquent bourriner plus le fichier temp. Or ça marche bien...
 
Je capte pas trop !

inner join, pas left bourdel !
 
t'as des (+) dans ta requête ? non. donc INNER
 
t'as vraiment envie de foutre Oracle par terre toi...
 
ensuite, c'est quoi la taille de tes champs ? genre des varchar2(4000) chacuns non ? c'est pas le nombre de champs qui est limité (enfin, si, il est limité aussi, mais pour ainsi dire impossible à atteindre), mais la taille des lignes. un distinct augmente vraissemblamement la taille des lignes lors du traîtement

Ok, merci magicBuzz je vais voir de ce côté là

En fait j'ai beau mettre les champs aussi petit qu'il se peut (à savoir que max j'ai des champs qui font varchar2(55), et ça ne change rien, j'ai toujours ce problème de File I/O.
 
Ma requête est-elle mauvaise ou alors y a t'il un moyen autre pour que je n'ai pas ce problème ?
 
En fait mon probleme est le suivant : j'ai 4 tables tmp_export_profils_portrait[1-2-3-4] et dans celles-ci je dois retirer pour une personne plusieurs informations dans 4 tables.
 
Pour moi la seule chose qui les rattache est pin_number (qui est l'id de la personne en question) et qu'on retrouve dans les 4 tables, donc ma question est la suivante :
 
Est-ce que les jointures de ma requete SQL est bonne ?
 

 
Par ce qu'au final j'ai des doublons qui ressortent
 
Merci

je dirais que t'es tombé sur un bug d'oracle.
 
vire un maximum de champs, puis rajoute-les un à un, jusqu'à ce que l'erreur se produise
 
dès qu'elle se produit, vire le champ qui pose problème, et tente un autre.
 
si ça continue de planter, bravo t'as gagné : un joli bug oracle.
 
à mon avis le distinct est limité à un nombre de champs bien définis, ou une connerie du genre.
 
 
ah... au fait. tu peux faire un select (sans le distinct) et lire toutes les lignes (genre tu lances la requête dans SQL+)
 
parceque ton truc ça me rappelle aussi ce qui se passe quand t'as un fichier de base corrompu : le distinct nécessite une lecture réelle de chaque valeur de chaque champs, alors que le select normal ne nécessite que la lecture des indexs et champs utilisés pour les filtres, donc si t'as des données corrompues à un endroit, il ne s'en rendra pas compte

tes jointures sont bonnes mais si tu ne mets pas de distinct tu te retrouves evidemment avec des doublons.
 
D'ailleurs ils proviennent de quelle table? Une table en particulieur ou tu as des données doublonnées dans les 4?

@MagicBuzz : Je fais tous mes tests sous PL/SQL developer, et oui je peux faire un select sans le distinct, ça ne pose pas de problème particulier.
 
@anapajari : j'ai des doublons dans les tables. je m'explique : En fait ces 4 tables ont plus ou moins la même architecture au niveau des champs, sauf que dans certaines il y a des champs en plus ou en moins, mais par exemple on aura toujours l'id, le nom et prenom d'une personne.  
 
Le but de ma requête est : pour une personne donnée, récupérer tout ce qui le concerne sur les 4 tables (en virant les champs qui se répètent).
 
Mais là je sèche avec cette histoire de distinct.
 
j'ai essayé une autre manière mais je crois qu'il va également me rajouter des doublons, je me trompe ?

essaye en faisant des sous-select qui contiennent le distinct de chaque table

Une autre question :
 
Sur les 4 tables, il y en a qui ont plus d'enregistrement que d'autres, si je veux récupérer toutes les données sur les 4 tables pour une personne et que pour les champs non renseignés (NULL), il ne me mette rien, il vaut mieux que je fasse un  
 

 
afin qu'il ne me mette pas des données comme cela (sorti fichier plat, champs séparés par un pipe :
 
||||||||||||||||Carte de Fidelite||DER|||||||||||||||||||
 
exemple de bon format :
 
1547697|13017|Mme|Fran|NEGRESSSSSSSS|fra.negre@toto.com|23, rue du BOURG|CHAMPIGNY|Carte de Fidelite||DER|
 
Je ne sais pas si vous voyez ce que je veux dire...

nan mais left outer c'est plus lisible que right
Et tu noteras que c'est pas ce que faisait ta requete initialle.

Bien sur, mais je n'y connais absolument rien en requete ca n'est pas mon domaine, c'est juste pour dépanner que je suis dessus, donc je test un peu

bon, et ce test dans SQL+ ?
 
SQL Developper, comme TOAD, ne fetch pas toutes les lignes, dont si des données sont corrompues, ça ne fera pas d'erreur.
 
moi je veux que tu fasse un SQL+ pour voir si tu te paies un message d'erreur au milieu.
 
 
 
si tu me crois pas, rempli une table avec des nombres de 0 à 1000
 
fait un "select 1/nombre from matable order by nombre desc"
 
et tu verras que sql developper ne fera pas d'erreur, alors que sql+ va te sortir un bon gros division par zero blue screen of death qui tue (bon, sans blue screen quand même, mais un joli message d'erreur )