Yello
 
Soit un fetch et une boucle toute bête.
Je sélectionne un champ date qui par défaut apparait yyyy-mm-dd, or je voudrais dd-mm-yyyy.
J'ai l'impression de foirer un truc tout bête dans mon ereg_replace, ou de ne pas le positionner au bon endroit (de la ligne ou du fetch)
 

 
 
Any idea ?

Le plus simple est de formater la date direct à la source (requête) :
 
select date_format(date_table,"%d-%m-%Y" ) from...
 
Sinon => ereg_replace("^([0-9]{4})-([0-9]{2})-([0-9]{2})$","\\3-\\2-\\1",$data[1])
 
T'as inversé l'ordre des éléments à afficher

J'ai mal interprété le "\\3-\\2-\\1", et donc oui j'ai fatalement inversé
Et formater dans le select, bien sûr ...  
 
Thanks  

C'était une réponse ironique ou... ?
(des fois, c'est pratique... des fois, moins )
 

Ca arrive les vendredi  
 
   
 

 
 
Non non, pas ironique ...
C'est ce que je fais d'habitude, mais je sais pas là j'avais un ereg_replace sous les yeux ...
 
edit : en effet, un date_format foire mon order by sur la date

le date_format foire rien du tout pour un tri (si xtof passe par là )
 
montre ta requête stp

 
Donne :
 
| AAA.AAAA.000  | 10-03-2006                     | 060  | #### | #### | 060    | #### |
| AAA.AAAA.000  | 13-02-2006                     |      | #### | #### | ------ | #### |
| AAA.AAAA.000  | 15-05-2006                     | 070  | #### | #### | 060    | #### |
| AAA.AAAA.000  | 16-02-2006                     | 060  | #### | #### | ------ | #### |
 
Item est dans l'ordre (oui, là y en a qu'un seul, mais c'est kifi kif), les dates pas

order by 1, 2   en mettant order by b.date ça irait pas mieux ?

Si , en effet
Mais je fais toujours by 1, 2, ...   (et je sais que c'est pas super, mais c'est plus court)
Si je mets b.date au lieu de format_date(...) et que je garde le order by 1, 2 asc : l'ordre est correct.
Y a un binz quelque part non ? En quoi le format_date (voire tout type de format sur un champ) réagit mal avec le order by 1, 2 ?
 
Pourquoi faire l'order by sur le jour (première valeur du champ 2) alors qu'à mon sens tout le format_date forme un seul champ ...
Ou alors il interprète format_date comme un 'string' et non comme une date ...

Ca fonctionne très bien comme ça ... Enfin, normalement
 
@Mosca : pour les dates, c'est normal, il va trier les dates par rapport à ton date_format donc le résultat n'est faux en soi
(ça te retourne bien un "string" et plus un "date" )

Tu rajoutes "b.date" dans ton select sans date_format et tu tries là-dessus
 
Edit : balise "gras"... ça marche pas dans les cpp
Je ne sais pas si j'ai été très compréhensible

Le order by 1, 2 ne fonctionne pas avec date_format ... Je peux te faire un screenshot des deux queries si tu veux
Ton astuce fonctionne, mais à quoi bon sélectionner 2x le champ juste pour l'order by, vu qu'après je dois le virer de mon fetch ...
Au final : ereg_replace est très bien

faire une regexp plutôt que d'avoir une requête explicite
 
c'est quand même plus "logique" d'avoir un vrai JOIN et un vrai nom de champ pour le tri non ??

Si tu veux un order by 1, 2 asc, t'as pas le choix...
Je ne voulais pas bousculer tes habitudes
 
Maintenant si tu veux une vraie solution sans avoir recours à une ereg
 

 
Ca va mieux une fois que j'ai mangé
Ca va te sortir la date formatée et ça va trier sur la date en format MySQL (yyyy-mm-jj)
 

Nan mais   , à la fin !
 
J'ai bien saisi, merci
Ca me semble toujours un peu "bizarre", mais bon ...    
En tous c'est bon à savoir pour les prochaines conversions de champs avec des order by 1, 2 ...
 
 

Qu'est ce qui te parait bizarre ?
 
Ce que j'ai mis en dernier à l'avantage d'être simple et fonctionnel
J'utilisais les "order by 1,2" de temps en temps mais ça montre vite ses limites
 

C'est pas de la mauvaise volonté
Y a sûrement un truc basique qui m'échappe.
Ma question est : je fais un "order by 2" sur "date_format" il fait un order sur le résultat du "date_format" qui est de type char et non date; si je fais un "order by b.date" il fait l'order sur un type date qui est néanmoins formatée ...
Je dois pas être clair ... Mais je vois pas la différence essentielle entre le order by 2 et order by b.date sur le date_format ...

c'est peut être un bug, cette syntaxe est pas très utilisée

Ok, je vois
Ca me parait super clair dans ma tête mais j'arrive pas l'expliquer
 
DATE_FORMAT(b.date,"%d-%m-%Y" ) te sort une date de type : dd-mm-yyyy
Si tu tries sur ce résultat, il va commencer par les jours; puis si les jours sont identiques, il va comparer les mois en plus; puis si les mois sont identiques, il va comparer les années en plus.
 
Ce qui te donne :

 
10 < 13 < 15 < 16...
Il ne tient pas compte des mois car il a pu trier sur les jours. Pour que ce soit trié correctement dans l'order croissant, il aurait fallu que les années et les mois soient identiques.
 
b.date te sort une date de type : yyyy-mm-dd (en ayant le date_format pour formater ta date en sortie, mais il n'intervient pas dans l'order)
Si tu tries sur ce résultat, il va commencer par les années; puis si les jours sont années, il va comparer les mois en plus; puis si les mois sont identiques, il va comparer les jours en plus.
 
Ce qui te donne :

 
En fait, quand tu veux trier une date, il faut le faire obligatoirement sur un format yyyy-mm-dd
C'est là que "order by 1,2" montre ses limites. C'est pour ça qu'il faut trier sur b.date (format yyyy-mm-dd) et non le date_format (dd-mm-yyyy, impossible de trier dessus)
 
Que ce soit un type varchar ou date en sortie ne change rien (ça reste une chaine de caractères au final pour le tri).
 

Le order by 2 trie sur le date_format en sortant le résultat du date_format.
Le order by b.date trie sur b.date en sortant le résultat du date_format.
 
En fait, la clause "order by" est dissociée du select. Tu peux trier sur un champ qui n'appartient pas à ton select (du moment qu'il appartient à une table du "from" )

Je me rends compte que j'ai carrément pas été clair

Non non, c'est bien ce que je pensais
Mais tu confirmes