Retourner aux forums || Retourner au forum Programmation.shell
Programmation.shell : Conversion de date pour import MySQL
Posté par mekare () le 29 avril 2008
Bonjour,
Je doit importer des fichiers texte contenant de nombreux champs (32) dans une table MySQL : Pour cela aucun problème j'utilise LOAD DATA.
Ce qui me dérange c'est le format de date de ces fichiers. Actuellement j'ai un format tel que ceci "jj/mm/aaaa hh:mm" et MySQL n'en veut pas en tant que format DATETIME. Je souhaiterais le convertir en shell avant import dans MySQL, j'ai donc pensé à AWK. Mais même si je connais un petit peu, je ne m'en sort pas : je ne sais pas modifier le format de ce champs tout en affichant les autres.
Je ne sais pas si je suis super clair... alors si vous désirez des questions complémentaires demandez moi.
Je doit importer des fichiers texte contenant de nombreux champs (32) dans une table MySQL : Pour cela aucun problème j'utilise LOAD DATA.
Ce qui me dérange c'est le format de date de ces fichiers. Actuellement j'ai un format tel que ceci "jj/mm/aaaa hh:mm" et MySQL n'en veut pas en tant que format DATETIME. Je souhaiterais le convertir en shell avant import dans MySQL, j'ai donc pensé à AWK. Mais même si je connais un petit peu, je ne m'en sort pas : je ne sais pas modifier le format de ce champs tout en affichant les autres.
Je ne sais pas si je suis super clair... alors si vous désirez des questions complémentaires demandez moi.
> Lire le message (2 commentaires, moyenne: 2).
date ?
Posté par
gronk34t () le 29/04/2008 à 11:57. (lien). Évalué à 2.
Est-ce qu'un truc comme ça ne ferait pas l'affaire ?
date -d $ta_date +%F\ %X
-
[^]Re: date ?
Posté par mekare () le 29/04/2008 à 13:18. (lien). Évalué à 2.En fait c'est bon, j'ai ma réponse ici : http://linuxfr.org/forums/26/24593.html
Revenir en haut de page || Retourner aux forums || Retourner au forum Programmation.shell



Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.