Discussion :

[pdelorme]

bonjour,

lors d'une requette ci dessous, les données me reviennent dans un ordre caractère-chiffre (respectivement trié correctement) alors que le bon sens voudrais que les données triés soit dans l'ordre chiffre-caractère...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 SELECT TABLE1.CHAMP
 FROM   
	TABLE1, TABLE2, TABLE3
 WHERE  TABLE1.x= TABLE2.X
 and TABLE2.Y = TABLE3.Y
 and TABLE1.z = "xxx"
 ORDER BY TABLE1.CHAMP

me retourne par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CHAMP
------
A
B
C 
D 
1
2
3

alors que j'attend :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CHAMP
------
1
2
3
A
B
C 
D

a noter que la requette

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT TABLE1.CHAMP
 FROM  TABLE1
ORDER BY TABLE1.CHAMP

me retourne mon champ dans l'ordre correct (chiffre-caractère)...

étonnant non?

je suis sous ORacle 9i, mais (pour la petite histoire) les table TABLE1, TABLE2, TABLE3 sont des vues construite sur un DBLink vers RDB (du type : view TABLE1 as select * from TABLE1@DBLINK)

des pistes?

merci.

Patrice.

[mnitu]

bonjour,

lors d'une requette ci dessous, les données me reviennent dans un ordre caractère-chiffre (respectivement trié correctement) alors que le bon sens voudrais que les données triés soit dans l'ordre chiffre-caractère...
...

Je ne suis pas certain que c'est une affaire de bon sens; je pense que c'est peut être une affaire de NLS_SORT.

[webfranc]

et si tu specifie ORDER BY TABLE1.CHAMP asc (ou desc) ?

[orafrance]

C'est bien NLS_SORT qui permet de définir si on trie sur le jeu de caractères ou la valeur binaire.

[pdelorme]

je regarde NLS_SORT maintenant,
mais comment expliquer que selon les cas le tri fonctionne dans un sens ou dans l'autre... plutôt étrange non? on dirais que la jointure perturbe le tri...

webfranc :
j'ai essayé en rajoutant asc à mon order by mais ca ne change rien...

P.

[orafrance]

pour info : http://fadace.developpez.com/oracle/nls/

les jointures peuvent effectivement changer l'ordre dans lequel Oracle récupère les données.

[pdelorme]

effectivement si je fait le tri de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT TABLE1.CHAMP
FROM TABLE1
ORDER BY 
	NLSSORT(TABLE1.CHAMP , 'NLS_SORT = GENERIC_BASELETTER');

Ma colonne champ sort trié correctement...

Cela dit... c'est un peut lourd et j'aimerais que ce tri soit celui par défaut (ce qui parais évident... chiffres-lettres)

Et comment expliquer (voir mon premier Post) que le tri par défaut ne soit pas le même selon les cas sans cette option NLSSORT ?

Patrice.

[orafrance]

Tu peux changer le paramètre au niveau de l'instance.

[pdelorme]

Tu peux changer le paramètre au niveau de l'instance.

c'est à dire?

j'ai trouvé comment changer le NLS_SORT au niveau de la session

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER SESSION SET NLS_SORT=FRENCH_M;

par contre ou est ce que je trouve la liste de tous les NLS_SORT possible?

j'aimerais que tous mes tris soit FRANCAIS mais avec l'ordre chiffre-lettre... j'ai essayer FRENCH_M qui à l'air bon (au pif) mais je n'ai trouvé aucune documentation sur le sujet. quelqu'un aurais t'il un lien vers la doc de référence?

Merci en tous ca... j'avance ;-)

P.

[orafrance]

c'est un paramètre de la base

[mnitu]

http://download.oracle.com/docs/cd/B...b14225/toc.htm

[pdelorme]

Cette histoire de NLS_SORT me pose un problème:
- je ne peux pas agir (a priori) sur la requette (elle est généré dynamiquement par crystal report).
- si je change NLS_SORT globalement sur ma base, j'ai peur d'insérer une régression sur d'autres programmes tournant sur la même base.

quelqu'un as t'il un retour sur une expérience de ce genre?

P.

[philcero]

Comme je l'ai déjà écrit dans d'autres post, il est bien souvent plus sûr et propre (si si) de positionner tout le fatra de paramétrage national dans un TRIGGER AFTER LOGON sur le compte applicatif.

Comme ça, fini les em...... avec les clients mal configurés et les incompatibilités entre schémas...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
CREATE OR REPLACE TRIGGER SCOTT_ALTER_SESSION AFTER LOGON ON SCOTT.SCHEMA
BEGIN
    execute immediate 'alter session set nls_date_format = ''dd.mm.yyyy hh24:mi:ss''';
    execute immediate 'alter session set nls_sort=binary_ci';
...etc...
END SCOTT_ALTER_SESSION;

[mnitu]

Cette histoire de NLS_SORT me pose un problème:
- je ne peux pas agir (a priori) sur la requette (elle est généré dynamiquement par crystal report).
- si je change NLS_SORT globalement sur ma base, j'ai peur d'insérer une régression sur d'autres programmes tournant sur la même base.

quelqu'un as t'il un retour sur une expérience de ce genre?

P.

Oui, mais Crystal Report se connecte à la base comme n'importe quelle autre application client, n'est pas vrai ? Et elle doit utiliser des valeurs NLS... définies quelque part, non ?

[pdelorme]

Oui, mais Crystal Report se connecte à la base comme n'importe quelle autre application client, n'est pas vrai ? Et elle doit utiliser des valeurs NLS... définies quelque part, non ?

à ma connaissance dans la base de registre (windows) du client... le problèmes c'est que du coup toutes les applis de la même machine "subissent" la meme config de session.

[pdelorme]

merci à philcero, cette solution me parais pas mal... je l'essaye...

cela dit...
quelqu'un peut-il expliquer POURQUOI le order by ne se comporte pas toujours de la même manière? (cf :premier post).

P.

[orafrance]

parce que la table n'étant pas ordonnée, Oracle n'a aucune raison de retourner le résultat toujours dans le même ordre. Et comme je l'ai dit, les jointures peuvent en plus changer l'ordre dans lequel les blocs sont récupérés sur le disque

[pdelorme]

parce que la table n'étant pas ordonnée, Oracle n'a aucune raison de retourner le résultat toujours dans le même ordre. Et comme je l'ai dit, les jointures peuvent en plus changer l'ordre dans lequel les blocs sont récupérés sur le disque

d'accord sans order by, mais dans mon cas je spécifie EXPLICITEMENT order by dans ma requette (cp POST #1). c'est quand même le but de Order by que de trier les résultat de façon cohérente, non... quelque chose m'échappe...

P.

[mnitu]

Est-ce que tes premières requêtes ont été exécutés à partir de la même session (idéal Sql*Plus)? Comment t'a exécuté ces requêtes (Sql*Plus, Crystal report, Toad, etc.) ?

[pdelorme]

- la requette problématique à été généré par crystal report, cela dit c'est du SQL Oracle correct... le problème de défaut de tri à été initialement détecté lors de l'execution de cette requette par crystal report.
- j'ai alors testé cette requette sous TOAD.
- mes premières requetes (post #1) ont été executés dans TOAD, même session, succesivement, sans changement entre deux...

pour ceux que SQL amuse, la requette généré par crystal report est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 SELECT 
	"DT_CALENDRIERS_TARIFS"."CAL_COD_BASE_TAR"
 FROM   
 	"RESERVADM"."DT_LIBELLES_TARIFS" "DT_LIBELLES_TARIFS", 
	"RESERVADM"."DT_MEDIA" "DT_MEDIA", 
	"RESERVADM"."DT_LIBEL_CODE_TAR" "DT_LIBEL_CODE_TAR", 
	"RESERVADM"."DT_LANGUE" "DT_LANGUE", 
	"RESERVADM"."DT_JOUR_SEMAINE" "DT_JOUR_SEMAINE", 
	"RESERVADM"."DT_TYP_USER" "DT_TYP_USER", 
	"RESERVADM"."DT_SAISON" "DT_SAISON", 
	"RESERVADM"."DT_SAISON_RESIDENCE" "DT_SAISON_RESIDENCE", 
	"RESERVADM"."VUE_ANNEE_RESIDENCE" "VUE_ANNEE_RESIDENCE", 
	"RESERVADM"."DT_RESIDENCE" "DT_RESIDENCE", 
	"RESERVADM"."DT_CATEGORIE" "DT_CATEGORIE", 
	"RESERVADM"."DT_CALENDRIERS_TARIFS" "DT_CALENDRIERS_TARIFS", 
	"RESERVADM"."VUE_TARIFS_HEBERGEMENT_GROUPE" "VUE_TARIFS_HEBERGEMENT_GROUPE", 
	"RESERVADM"."DT_DEVISE" "DT_DEVISE", 
	"RESERVADM"."DT_LIBEL_BASE_TAR" "DT_LIBEL_BASE_TAR"
 WHERE  
 	("DT_SAISON"."NO_SAISON"="DT_SAISON_RESIDENCE"."NO_SAI") 
 AND ("VUE_ANNEE_RESIDENCE"."CODE_RESIDENCE"="DT_RESIDENCE"."COD_RSD") 
 AND ("DT_SAISON_RESIDENCE"."COD_RESID_SAI"="DT_RESIDENCE"."COD_RSD") 
 AND ("DT_RESIDENCE"."CAT_RSD"="DT_CATEGORIE"."COD_CATEGORIE") 
 AND ("DT_RESIDENCE"."COD_RSD"="DT_CALENDRIERS_TARIFS"."CAL_COD_RSD") 
 AND ("DT_TYP_USER"."IDTYPEUSER"="DT_CALENDRIERS_TARIFS"."CAL_IDTYPUSER") 
 AND ("DT_JOUR_SEMAINE"."JRS_ID" (+)="DT_CALENDRIERS_TARIFS"."CAL_JRS_ID") 
 AND ("DT_LANGUE"."COD_LANGUE"="DT_CALENDRIERS_TARIFS"."CAL_COD_LANGUE") 
 AND ("DT_LIBEL_CODE_TAR"."COD_CODE_TAR"="DT_CALENDRIERS_TARIFS"."CAL_CODE_TAR") 
 AND ("DT_MEDIA"."COD_MEDIA" (+)="DT_CALENDRIERS_TARIFS"."CAL_COD_MEDIA") 
 AND ("DT_LIBELLES_TARIFS"."LIT_CAL_ID"="DT_CALENDRIERS_TARIFS"."CAL_ID") 
 AND ("DT_LIBELLES_TARIFS"."LIT_ID"="VUE_TARIFS_HEBERGEMENT_GROUPE"."LIT_ID") 
 AND ("DT_CALENDRIERS_TARIFS"."CAL_COD_DEVISE"="DT_DEVISE"."COD_DEVISE") 
 AND ("DT_CALENDRIERS_TARIFS"."CAL_COD_BASE_TAR"="DT_LIBEL_BASE_TAR"."COD_BASE_TAR") 
 AND "DT_CALENDRIERS_TARIFS"."CAL_COD_DEVISE"='E' 
 AND "DT_CALENDRIERS_TARIFS"."CAL_COD_LANGUE"='F' 
 AND "DT_CALENDRIERS_TARIFS"."CAL_DUREE_MIN">=4 
 AND "DT_CALENDRIERS_TARIFS"."CAL_DUREE_MAX"<=999 
 AND "VUE_ANNEE_RESIDENCE"."ANNEE_COMMERCIALE"='2009' 
 AND "VUE_ANNEE_RESIDENCE"."DATE_DEBUT"<"DT_CALENDRIERS_TARIFS"."CAL_DATE_FIN_PERIODE" 
 AND "VUE_ANNEE_RESIDENCE"."DATE_FIN">"DT_CALENDRIERS_TARIFS"."CAL_DATE_DEBUT_PERIODE"
 ORDER BY "DT_CALENDRIERS_TARIFS"."CAL_COD_BASE_TAR"

==>>> retourne des valeurs triés dans l'ordre alpha puis numerique


ma deuxieme requette de test :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 SELECT 
	"DT_CALENDRIERS_TARIFS"."CAL_COD_BASE_TAR"
 FROM   
 	"DT_CALENDRIERS_TARIFS"
 ORDER BY "DT_CALENDRIERS_TARIFS"."CAL_COD_BASE_TAR"

==>>> retourne des valeurs triés dans l'ordre numerique puis alpha

bizare non?

P.