En fait j'ai cherché à comprendre le problème :
puisque Galette ne devait avoir aucune raison de buguer sur un tri.
La fonction ORDER BY étant intégrée dans SQL .
Des données ont été importées avec une espace typographique et d'autre
sans !
Du coup il y a un tri logique tout ce commence par une espace est donc
placée en tête.
Ces problèmes d'espace sont un classique car difficile à détecter... et
à prévoir !
l'analyse par phpMyAdmin a révélé le problème.
Mes excuses encore.
Le 16/05/12 16:39, Johan Cwiklinski a écrit :
Le 16/05/2012 08:51, André Lefranc a écrit :
les tentatives de tri des adhérents sur le critère des états des
cotisations donne un résultat non cohérent :
voir ci dessous exemple de résultat (anonymisé)
Adhérent En retard de 135 jours (depuis le 02/01/2012) 12/05/2012
Adhérent En retard de 228 jours (depuis le 01/10/2011) 14/05/2012
Adhérent 132 jours restants (fin le 26/09/2012) 15/05/2012
Adhérent N'a jamais cotisé : Inscrit depuis 258 jours (depuis le
01/09/2011) 11/03/2012
Adhérent 10 jours restants (fin le 27/05/2012) 12/03/2012
Trésorier 98 jours restants (fin le 23/08/2012) 11/03/2012
Délégué Général 269 jours restants (fin le 10/02/2013) 11/03/2012
Adhérent N'a jamais cotisé : Inscrit depuis 228 jours (depuis le
01/10/2011) 01/10/20119
Adhérent N'a jamais cotisé : Inscrit depuis 228 jours (depuis le
01/10/2011) 01/10/2011
Adhérent N'a jamais cotisé : Inscrit depuis 228 jours (depuis le
01/10/2011) 01/10/2011
l'ordre ne correspond ni aux dates d'échéance ni aux dates
d'enregistrement.
Ce n'est pas censé être le cas et ça ne l'a jamais été dans galette, à
ce que j'en sache.
L'ordre de tri est le suivant :
ORDER BY "date_crea_adh" DESC, "bool_exempt_adh" DESC, "date_echeance"
DESC, "nom_adh" DESC
Il correspond à peu de chose près à ce qui existait en 0.62 et en 0.63.
Bon à savoir !!!
donc l'ordre est cohérent...
Merci