Resultat différent entre client Unix et Windows

[fredviry]

Bonjour,

J'exécute une requête SQL sur une base oracle 9.2.0.5 installée sur serveur Unix. L'ordre d'affichage des résultats est différent si le client oracle est sur Unix ou sur Windows. Le client Oracle sur Windows affiche dans l'ordre croissant la 1ere colonne IOLOTN (en fonction des autres paramètres de la commande).
Le client Oracle sur Unix affiche dans n'importe quel ordre la 1ere colonne IOLOTN (en fonction des autres paramètres de la commande).

Ci-dessous la requête que je ne peux pas modifier (hormis les valeurs).

Code :

1
2
3
SELECT IOLOTN, IOLOTS, IOMCU, IOITM, IOMMEJ
  FROM PRODDTA.F4108
 WHERE  ( IOITM = 716607.000000 AND IOMCU = '       01M01' ) AND  ( IOMMEJ >= 111089 AND IODLEJ <= 111089 )  ORDER BY IOITM ASC,IOMCU ASC,IOMMEJ ASC ;

La plan d'exécution indique que la requête utilise un index dont voici les paramètres.

Code :

1
2
3
IOITM	NUMBER	1
IOMCU	NCHAR	2
IOLOTN	NCHAR	3

Ci-dessous le résultat obtenu avec le client Unix. La 1ere colonne n'est pas classée par ordre croissant.

IOLOTN IOLOTS IOMCU IOITM IOMMEJ
------------------------------ ------ ------------ ---------- ----------
0786K 01M01 716607 113276
0786B 01M01 716607 113276
0786E 01M01 716607 113276


Cette différence d'affichage entre Unix et Windows est-elle connue ?
Comment peut-on classer par ordre croissant la 1ere colonne sans devoir toucher à la requête SQL ? Faut-il créer un autre index ?

Merci d'avance

[ojo77]

La seule et unique façon d'obtenir un tri dans un ordre SQL est de le préciser dans la clause order by. Dans le cas contraire le fait que le résultat soit trié à l'affichage résulte souvent du hazard.

En complément : Avant la 10g, group by entrainait un tri, depuis la 10g Oracle fait du "hash group by" et ne trie donc plus sur les colonnes de regroupement.

[mnitu]

Regardez les paramètres NLS_SORT, NLS_COMP sur les deux bases.

[ojo77]

Envoyé par mnitu

Regardez les paramètres NLS_SORT, NLS_COMP sur les deux bases.

Il n'y a qu'une base, c'est le client qui change ...

[mnitu]

Envoyé par ojo77

Il n'y a qu'une base, c'est le client qui change ...

Merci, j'avais lu un peu à travers mais, cela ne change rien. Regardez les paramètres en question dans la vue NLS_SESSION_PARAMETERS pour les deux sessions.

[pachot]

Bonjour,

En fait, aucun des 2 résultats n'est trié sur IOLOTN puisque l'order by est sur IOITM ,IOMCU ,IOMMEJ .
C'est un hazard. si ca te semble trié: il se trouve que les IOLOTN sont arrivés physiquement dans le bon ordre. Donc leur rowid se sont trouvés dans le bon ordre et la lecture par index, avec certains paramètres NLS, n'est pas suivie d'un tri et ça arrive comme ça. Avec d'autres paramètres, il y a un tri ensuite sur IOITM ,IOMCU ,IOMMEJ mais toujours pas sur IOLOTN.

Seules solutions: changer la requête ou retrier sur le client.

Cordialement,
Franck,

[fredviry]

Bonjour,

Merci pour vos réponses.
Je ne peux pas toucher aux requêtes (il s'agit d'un traitement JDEdwards). Vous me proposez de trier sur le client. Comment dois-je m'y prendre ? Y-a-t-il un paramètre spécifique au client ?

J'ai lancé à de nombreuses reprises et en même temps cette requête sur client Unix et Windows. A chaque fois, la colonne IOLOTN est triée avec le client Windows et cette même colonne est dans le désordre avec le client Unix. C'est vraiment frustrant.

Merci

Frédéric

[fredviry]

Sur le client Unix, le paramètre NLS_SORT est positionné à BINARY.
Sur le client Windows, le paramètre NLS_SORT est positionné à FRENCH.

Je modifie le paramètre NLS_SORT sur le client Unix.

Code :

ALTER session SET NLS_SORT='FRENCH';

Je lance ensuite la requête SQL. Cette fois-ci, la colonne IOLOTN est triée.
Génial ! Je souhaite conserver ce paramètre sur le client Unix. A votre avis, quel est l'impact de la modification de ce paramètre ?

Merci

Frédéric

[mnitu]

Linguistic Sort Parameters
Mais vous devez comprendre que tant que la requête n'utilise pas d'Order by sur la colonne IOLOTN votre tri n'est pas fiable.