Version imprimable
Bonjour,
j'essaie de mettre à jour une table avec un fichier .txt en lançant le requête SQL suivante :
Il prend bien la 1ère ligne mais après ça part en vrille : toutes les autres entrées sont vides ou prennent la valeur par défaut… :(Code:
2
3
J'ai pourtant bien vu que les lignes se finissaient avec un \p
Qu'est-ce qui pourrait provoquer ça ?
Le saut de paragraphe n'est pas \p mais \r.
Merci pour ta réponse malheureusement ce n'est pas encore gagné :
avec \r
je n'ai que le 1er élément qui est ajouté à la table (donc la 1ère ligne du fichier texte)
avec \p
j'ai plusieurs lignes mais seule la 1ère est cohérente. Les autres n'ont pas les bonnes valeurs. Les champs sont soit nuls, soit vides…
:(
Une autre idée ?
'\r\n' (classique Windows)
Malheureusement toujours …
ni '\r\n' ou '\n\r', ni '\p\n' ou \n\p' ne fonctionnent… :cry:
(tant que j'y étais j'ai essayé ces autres combinaisons…)
Le résultat est toujours une seule ligne…
Si je fais un copier/coller du saut de ligne dans Word j'obtiens ^p
ça revient donc bien \p non ?
C'est peut-être dans mon export d'Excel que je n'ai pas choisi le bon format ?
Je suis sur Mac.
J'ai mis "Texte avec séparateur tabulation"…
Et \n tout seul ?
Sinon, édite le fichier avec un éditeur hexadécimal et regarde le code hexa des fins de lignes. Ca peut donner une indication...
ced
Non. Il n'y a aucun rapport entre Word et MySQL.Citation:
Envoyé par Mister Paul
Le retour chariot (saut de paragraphe) est le caractère 13. Il est représenté dans Word par ¶ (à l'affichage) et ^p (dans une recherche), et dans MySQL par \r.
Si c'est du Mac OS X, c'est du Unix, donc je rejoins ced, ça doit être '\n' (le saut de ligne simple, ou caractère 10). C'est quand même bizarre que ça te donne ^p dans Word...Citation:
Envoyé par Mister Paul
ça c'est le FIELDS TERMINATED BY '\t', mais ça ne dit rien sur le séparateur de lignes.Citation:
Envoyé par Mister Paul
Ça ne fonctionne toujours pas…
Avec un éditeur hexadécimal :
saut de champ : 09
saut de ligne : 0D
:(
09 : caractère 9, donc tabulation, donc '\t', tout est OK là-dessus
0D : caractère 13, donc '\r'
Je pense que le problème vient des \r qui doivent être dans les valeurs... j'ai déjà constaté que les mettre entre guillemets ne suffisait pas.
Ben je n'ai pas vu de \r dans les valeurs.
Par ailleurs si je fais une recherche avec Word dans le fichier txt :
- ^p me donne toutes les fins de lignes
- ^t me donne les tabulations entre les champs… MAIS je remarque des choses étranges :
- une tabulation au lieu d'un espace entre 2 mots d'un même champ…
- plus de 300 entrées dans la table au lieu de 30…
Un gros problème d'encodage depuis l'export Excel ?
Il y a une procédure plus sûre que de passer par Excel/Word ?
(je suis sur Mac)
ça doit pas aider !Citation:
Envoyé par Mister Paul
D'où viennent tes données ?Citation:
Envoyé par Mister Paul
A la base j'ai fait un export en Microsoft Excel 2000 depuis ma table avec phpMyAdmin…Citation:
D'où viennent tes données ?
Alors fais plutôt ton export avec mysqldump. Passer par Word et Excel pour faire du MySQL vers MySQL, c'est assez tordu !
Oui évidemment c'est tordu !
Sauf qu'entre-temps je dois travailler sur le fichier Excel de manière bureautique pour le compléter…
Sauf meilleure idée, je chercherais donc plutôt à sécuriser le processus via Excel/Word… :oops:
Peux-tu déjà zapper le passage par Word ?
J'ai refait le processus en remplaçant Word par BBedit :
même problème !
:oops:
Mais je viens de remarquer que tous les p du texte sont considérés comme des fins de ligne 8O
J'avais mis : LINES TERMINATED BY '\p'
Comme tu dis avec Word pour la fin de ligne c'est :
0D : caractère 13, donc '\r'
J'ai essayé :
LINES TERMINATED BY '\r'
LINES TERMINATED BY '\r\n'
LINES TERMINATED BY '\n\r'
mais je n'obtiens qu'une seule ligne saisie dans la table…
C'est bien la fin de ligne qui pose problème.
Avec BBEdit mes fins de lignes sont indiquées comme ça en hexadécimal :
E2 80 A8
Ouh la la…
;)
Pourquoi as-tu besoin de passer par un éditeur de texte ?Citation:
Envoyé par Mister Paul
bah oui, comme '\p' ne correspond à aucun code, c'est comme si tu écrivais LINES TERMINATED BY 'p'.Citation:
Envoyé par Mister Paul
ça correspond à '
'... à tout hasard, essaie unCitation:
Envoyé par Mister Paul
mais je doute beaucoup...Code:LINES TERMINATED BY '
'
LINES TERMINATED BY '
'
Effectivement ça ne marche pas…
Ben sinon je passe par un éditeur de texte pour remplacer les "" par des \" (enfin j'ai lu qu'il fallait faire ça…).
J'ai essayé d'exporter directement le xls en txt :
ça marche assez bien MAIS :
- dès qu'il y a un caractère accentué ça coupe les données du champ
- les nombres, dates et heures ne passent pas…
Euh il n'y a pas une procédure simple et fiable pour mettre à jour une table avec Excel ? :?
Bon ce que j'ai fait finalement et qui fonctionne pour moi sur Mac avec le problème de caractères accentués :
Export de la table :
1° Export de la table en XLS 2000 depuis phpMyAdmin
2° OK je peux travailler sur le fichier Excel qui se crée…
(…)
Import de la table :
1° Enregistrer le fichier Excel sous csv
2° Le réouvrir avec BBEdit en MacRoman puis le sauver en Unix utf-8 No Bom
3° Importer avec phpMyAdmin en CSV via LOAD DATA et avec \n en caractère de fin de ligne
J'ai mis le temps… :aie:
Par contre je suis obligé de vider la table avant d'importer parce que même si "Remplacer les données de la table avec le fichier" est coché ça semble ne pas remplacer…