Discussion :

[Unkof]

Bonjour,

Un petit problème de tri.

Je lis le contenu d'une base via un "SELECT Designation FROM Articles ORDER BY Designation ASC". J'ai un affichage genre :

Code :

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

1
2
3
4
5
6
 
100 Feuilles ...
10 Cartons ...
1 Feuille ...
A...
B...

Là ce qui m'étonne, c'est qu'il classe 100 Feuilles, 10 Cartons, 1 Feuille dans l'ordre alpha ca devrait être 1 Feuille, 10 Cartons et après 100 Feuilles.. mais bon.

J'ai bien sûr la possibilité de trier cette colonne via un simple clic sur le titre de la colonne, mais lorsque je reviens dans l'ordre ASC (en cliquant 2 fois donc ...) mon ordre d'affichage a changé, cette fois il est bien dans l'ordre ASC j'ai :

Code :

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

1
2
3
4
5
6
 
1 Feuille ...
10 Aimants ...
100 Feuilles ...
A...
B...

Le tout est dans une table mémoire.

Y a une possibilité d'avoir exactement le même ordre entre la requete SQL et le Tri de la barre de titre ?

Comment reproduire en code le tri que WinDev effectue au niveau de la barre de titre ?

Quelqu'un a une idée ?.. parce que là je sèche ...

[LeDièse]

Salut, aide-là

[Unkof]

Je pense que t'as lu mon message en diagonale.

Je ne vois pas le rapport entre la doc d'utilisation du traitement d'ordre de tri des colonnes et ce que je demande.

[laurent30s]

Peux-tu nous montre le code comment tu remplis la table ?
.

[Unkof]

Code :

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

1
2
3
4
5
6
7
 
HExécuteRequêteSQL(requete,"SELECT Designation FROM Articles ORDER BY Designation ASC")
HLitPremier(requete)
TANTQUE PAS HEnDehors(requete)
	TableAjoute(Table1,requete.Designation)
	HLitSuivant(requete)
FIN

[frenchsting]

"100 " est avant "10 " et avant "1 ", c'est logique, car les chiffres sont avant les autres caractères dans les tris alphanumériques.

[Unkof]

Frenchsting:Non, je ne suis pas d'accord.

Le tri est effectué par le code ASCII du caractère, un " " (espace) a le code ASCII 32, alors qu'un "0" à le code ASCII 48, sur un tri croissant il vient donc après.

Si tu fais la même requête de tri sous MySQL ou MSSQL par exemple, t'auras en affichage d'abord le "1 ", ensuite le "10 ", ensuite le "100 ".

D'ailleurs, quand tu fais le Tri croissant en cliquant sur la fonction de Tri de la barre de titre, il n'y a pas d'erreur.

Bizarrement, l'erreur apparait sur le HexecuterequeteSQL ..

Je viens de faire la même requete sous le CCHF, il me classe les 100 avant les 10 et les 1, pareil en cliquant sur la barre de titre de la colonne pour le Tri croissant ... spécificité Hyperfile ?

C'est dingue de ne pas avoir le même comportement au niveau du tri croissant des titres colonnes entre WinDev et CCHF ....

Enfin bref, j'en reviens au sujet du départ, comment avoir exactement le même Tri, en code et en cliquant sur le Tri de la barre de titre ?

Même si je dois virer la requete pour la remplacer par HLIT + HFILTRE ? ..

Comment on fait un tri croissant avec le WLangage sans utiliser de requete (à la lecture des enregistrements de la bdd, évidemment) ?

Je ne parle pas bien sûr d'un tri de table ..

[laurent30s]

Bonjour

J'ai essayé de reproduire ton problème
- j'ai crée un fichier articles en hyperfile avec les 5 valeurs dans le mauvais ordre 100,10,1,A,B
- j'ai ajouté une table à remplir en programmation, avec une colonne, tel que windev la crée
- j'ai mis ton code dans un bouton

quand je joue ton code la table se rempli avec les valeurs dans le bon ordre 1,10,100,A,B

C'est bizarre...
y-a forcément quelque chose mais quoi ???

[tatayo]

Bonjour,
Il n'y a pas une option dans les rubriques HF (ou est-ce dans les indexes ?) pour prendre en compte ou pas les espaces, la ponctuation, etc... dans les recherches ?

Peut-être que ça affecte aussi le tri dans les requêtes.

Tatayo.

[Unkof]

Bon, j'ai un peu avancé.

J'ai trouvé comment avoir le même "rendu", en ignorant toutes les options de Tri au niveau du tri de la colonne. Maintenant quand je clique dessus, j'ai exactement le même ordre que ma requete.

Laurent30s, suite à ton message, j'ai refait moi aussi comme toi un petit test en partant de zéro, une nouvelle base, j'ai saisie mes valeurs, et avec la même requete, je trouve le bon ordre d'affichage, à savoir 1, 10, 100, A, B.

Vu que dans ma base d'origine, ce sont des données d'imports je me suis dis que j'avais peut être un caractère caché (genre x0a, 0xd..) au niveau de la chaine de désignation. J'ai édité vite fait la base HF en hexadécimal, et non .. rien du tout, il n'y a pas de caractère invisible au niveau de la chaine ...

Tatayo:Oui, je l'ai vu avant de voir ton message, et j'ai réglé partiellement mon problème d'affichage lors du Tri croissant.

Par contre ca n'affecte pas la requete, j'ai fait des tests pour vérifier ... et j'ai toujours mon problème d'affichage de 100,10,1 au premier rendu de la requete .. je cherche encore.

[laurent30s]

hohohoooooo !!!
je crois avoir trouvé ce qu'il t'arrive... du moins je l'espère...

C'est le message de tatayo qui m'a orienté et le fait que tu ais éliminé la possibilité d'un caractère caché.

J'ai mis la rubrique désignation en clé doublon et quand je lance la requête bingo 100,10,1,A,B on reproduit le problème

Il suffit de cocher sensible aux espace, ponctuation et car. spéciaux pour que ça ce mette dans le bon ordre

C'est quand même un peut tordu que le bon ordre ne soit pas celui par défaut.
En tout cas c'est à savoir...
.

[frenchsting]

Frenchsting:Non, je ne suis pas d'accord.

Exact. grossière erreur de ma part.

La solution de Laurent30s me paraît judicieuse. J'avais déjà eu des soucis de recherche (fonctions Hxxx) qui me donnait des résultats incohérents losqu'il y avait des caractères de ponctuation dans les chaines.

[Unkof]

Laurents30:C'est exactement ca

Je n'avais même pas vu qu'on peut modifier les paramètres d'index.

Merci à tous pour la participation, et merci donc à toi Laurents30 pour la solution