Problèmes de tri

bonjour,

j'ai un petit souci concernant le tri.
en fait, je tri sur une colonne d'integer (positifs, négatifs ou nuls).

quand je fais le tri normal (order by MaColonne) le tri marche parfaitement.

par contre, quand j'ecris ca, cela ne marche plus (enfin ca marche sauf que j'ai les entiers négatifs toujours en extrémité et apparamment ils ne sont pas inclus dans le tri :

Code:

---

1 2 3 4 5

SELECT t1.* FROM (SELECT ID, NUMERO, AVOIR FROM MyTable ORDER BY DECODE(:champTri, 'ID', ID, 'NUMERO', NUMERO, ID)) t1 ORDER BY ROWNUM * (:sensTri)

---

où champTri (string) et sensTri(integer) sont des variables que j'alimente ailleurs.

Par ex, en l'occurrence pour l'exemple que je vous ai expliqué, pour sensTri=-1 et champTri = 'AVOIR', j'aurais le tri descendant sur la colonne AVOIR.
Le pb est que pour des valeurs de la colonne AVOIRS comme suit:
-10
-5
0
10
20
..
j'aurai un tri descendant de la forme
-10
-5
20
10
0

je ne vois pas d'ou provient le souci du moment qu'un simple order by marche parfaitement, donc ce ne peut pas etre un problème de string et d'integer!
j'ai essayé pour d'autres colonnes et ca marche très bien.. ya que les nombres négatifs qui foutent le b...

Merci

pourquoi trier sur ROWNUM ? ROWNUM c'est forcément dans l'ordre croissant puisque c'est le numéro de la ligne :koi:

Et sous cette forme ...

Code:

---

1 2 3 4 5

SELECT rownum * SIGN(:sensTRI), t1.* FROM (SELECT ID, NUMERO, AVOIR FROM MyTable ORDER BY DECODE(:champTri, 'ID', ID, 'NUMERO', NUMERO, ID)) t1 ORDER BY 1

---

J'avais lu ça dans le journal d'Oracle : Le TYPE du DECODE est celui de la premiere valeur. Soit ici le type de champTri : VARCHAR2
Il va donc trier la chaine DECODE(:champTri, 'ID', ID, 'NUMERO', NUMERO, ID)
comme du VARCHAR2.

Chez moi par contre ça marche, j'ai les bons tris en faisant ta requete.

Je te renvoies aussi sur la discussion des différences entre comparaison et tri.
http://www.developpez.net/forums/sho...light=NLS_COMP

Chez moi (9.2.0.1):

Code:

---

1 2 3 4 5 6 7 8

SELECT '-10' FROM dual UNION SELECT '0' FROM DUAL ORDER BY 1   => '0' puis '-10'

---

A l'inverse

Code:

---

1 2 3 4

SELECT 1 FROM dual WHERE '0' > '-10'   => 1

---

bon je sais ce qui cloche..
c'est effectivement le decode!!

en fait, :champtri est de type varchar2 (bien entendu car je fais le tri selon l'INTITULE de la colonne que je désire)
le decode "croit" que toutes les colonnes que je lui envoie pour le tri sont de type varchar2.

la solution serait de mettre les numéros de colonne au lieu des intitulés de colonnes, ce qui mettrait :champtri à integer et ca résout le pb, sauf que ce n'est pas du tout pratique car j'ai besoin de récupérer l'intitulé de la colonne et je ne vais pas imposer à l'utilisateur de connaitre tous les numéros de colonne!!

voila..

je suis allé sur le lien que tu m'as envoyé et je n'ai pas trouvé de traces sur le pb du decode..

Citation:

---

Envoyé par McM

J'avais lu ça dans le journal d'Oracle : Le TYPE du DECODE est celui de la premiere valeur. Soit ici le type de champTri : VARCHAR2

---

Non, je ne suis pas d'accord avec toi. C'est le type de la première valeur résultat qui est pris en compte, ici la colonne ID.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

SQL> desc table1 Name Null? Type ------------------------------- -------- ---- A NUMBER B NUMBER   SQL> create view vue_table1 as select decode ('b', 'a', a, 'b', b) tri from table1; View created.   SQL> desc vue_table1 Name Null? Type ------------------------------- -------- ---- TRI NUMBER

---

La première colonne du decode est bien de type varchar2, mais le type résultant est bien number car la colonne a est number.

Maintenant si je fais :

Code:

---

1 2 3 4 5 6 7

SQL> create view vue2_table1 as select decode ('b', 'a', 'toto', a, 'b', b) tri from table1; View created.   SQL> desc vue2_table1 Name Null? Type ------------------------------- -------- ---- TRI VARCHAR2(40)

---

Ma colonne tri est désormais de type varchar2, car la première colonne résultat du decode est de type varchar2.

[EDIT]
Il est d'ailleurs intéressant de constater que cette conversion implicite faite par le decode n'est pas supportée par le case when :

Code:

---

1 2 3 4 5

SQL>create view vue3_table1 as select (case when 'a' = 'a' then 'a' else b end) tri from table1; create view vue3_table1 as select (case when 'a' = 'a' then 'a' else b end) tri from table1 * ERROR at line 1: ORA-00932: inconsistent datatypes: expected CHAR got NUMBER

---

[/EDIT]

effectivement..
après qqes tests, je suis arrivé au même résultat! c'est donc le type de la première valeur renvoyée à Decode comme tu dis!

mais ca me renvoie tjs au même problème.

j'ai des colonnes de type différent (integer, varchar2 et date)
je veux faire un tri selon l'intitulé de la colonne en utilisant un decode, ce qui me fait:

Code:

---

orderby decode(:champtri, Somme, 'Somme', Nom, 'Nom', Date, 'Date', Nom)

---

où champtri est de type varchar2.

aucune solution ne marche pour tous ces types en même temps.
Meme en reseignant le numero

Code:

---

decode(:champtri, 1,1,2,2,3,3,1)

---

où champtri est de type integer--> ca résout le pb des nombres mais pas celui des dates..

est ce que qqn voit une solution?? ou même une suggestion.. merci

Personnellement je fais autant de decode que j'ai de type de données :

Code:

---

1 2 3 4 5

select * from matable order by decode (:champTri, 'A', colNum1, 'B', colNum2), decode (:champTri, 'C', colDate1, 'D', colDate2), decode (:champTri, 'E', colChar1, colChar2);

---

Une autre solution est de faire une requête dynamique.

et ça marche ton truc??

j'ai essayé chez moi et j'ai toujours les mêmes soucis...

autant pour moi...:mouarf:
ca marche très bien

Merci bp..

je pense que cela fera un bon post, surtout avec le sens de tri paramétrable que j'ai inclus au début..

encore merci

Exact : Mea Culpa (mais j'avais lu ça il y a 3 ans, j'ai une excuse :mouarf: )

Mais bon, Freesstyler a écrit :

Citation:

---

en fait, je tri sur une colonne d'integer (positifs, négatifs ou nuls).

---

C'est pas exactement ça alors.
Quel est le desc des champs du decode ?

c parce que j'ai essayé d'isoler le pb, alors qu'il ne s'agissait pas spécialement des integers, mais de n'importe quel autre type renseigné..

donc il faut finalement autant de decode que de types!

Merci pour la discussion, c'était très instructif!