Question botoujours en voulant écrire des procédures stockées dans une base ingres, j'ai des soucis pour écrire un 'select union)
la compil passe, l'éxécution ne plante pas, mais cela ne renvoie pas les valeurs souhaitées
mon select :
select col1,
col2,
col3,
col4
into :wcol1,
:wcol2
:wcol3,
:wcol4
from table 1
where col3='toto'
union
select col1,
col2
col3,
col4
from table2
where col3='toto'
je dois trouver une ou plusieurs lignes soit dans la table1 soit dans la table2 (pas dans les 2 en même temps)
quand je récupère mes données :
- si la ligne est dans table1 ==> ok j'ai les bonnes valeurs dans wcol1,wcol2,wcol3,wcol4
- si la ligne est dans table2 ==> j'ai les valeurs ok dans wcol1 et wcol2, mais rien dans wcol3,wcol4
si j'inverse le select (si je mets table2 en premier select et table1 en deuxième select) et que la ligne à trouver est dans table2, j'ai les bonnes valeurs !
je ne sais pas comment écrire ce select.
je ne peux pas mettre de INTO aprés le 2ème select (çà plante à la compil)
comment faire ??
merci de votre aide
Answer re bonjour,
Je vous passe les excuses sur la lenteur de ma réponse, je les ai déjà présentées il y a peu.
Le résultat d'un SELECT doit être le même, en théorie (si les données sont identiques), le même quelque soit le contexte (isql, db proc, ABF, embeded C, etc). Encore une fois cela s'entend sur un jeu de données identique (par exemple le même ordre SQL passé sur la même base, dont les données n'ont pas bougé entre temps).
Dans votre cas, le SELECT devrait retourner le même résultat sous isql et dans une DB Proc, quel que soit le sens d'écriture de la requête (contrairement à d'autres SGBD la manière dont on rédige la requête n'impacte en théorie ni l'exécution ni les performances). SI ce n'est pas le cas, il s'agit peut-être d'un bug Ingres (cela arrive).
Si votre client/employeur dispose d'un contrat de support auprès de l'éditeur il faut ouvrir un appel, puis espérer un patch pour la résolution.
Dans le cas contraire, il y a des choses à faire pour tenter de s'en sortir tout seul hors l'appel au support :
1/ confirmer que la même requête exactement se comporte différemment entre la DB proc et isql
2/ tentez de trouver l'écriture qui vous convient (et le résultat qui va avec) et faites en une vue de votre SELECT ... UNION (CREATE VIEW toto AS SELECT ... UNION) et retestez votre procédure en utilisant la vue plutôt que le SELECT ... UNION directement dans la DB proc.
3/ mais la solution n'est pas jolie du tout : passez par une table temporaire (DECLARE GLOBAL TEMPORARY TABLE) pour remplacer votre SELECT ... UNION
Sinon il y a une dernière chose qui me vient à l'esprit : par défaut le UNION élimine les doublons. Ce sont peut être des enregistrements en double que vous cherchez aujourd'hui. Dans ce cas il y a le mot clé ALL à ajouter à la suite UNION pour indiquer à Ingres de ne pas éliminer ces doublons.
Encore une fois n'hésitez pas à revenir vers moi en cas de besoin, etc etc ;-)
