Discussion :

[Korben-Dallas]

Bonjour,

Je rencontre un pb lors de l'importation de CSV dans ma table.
Lorsque j'exécute la requête suivante directement dans phpmysql, le fichier est bien importé mais dès que je le fait en php alors là j'ai un message d'erreur sur la requête.
Pourriez-vous me dire où se situerait cette erreur svp ?

Requête PHP :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
<?php
  $RequeteInjectionGestionSite = "
LOAD DATA INFILE 'D:\\xampp\\htdocs\\MonSITE\\UpLoad\\MonFichier.csv'
     INTO TABLE `t_GestionSites`
     FIELDS TERMINATED BY ';'
     ENCLOSED BY '\\'
     ESCAPED BY '\\'
     LINES TERMINATED BY '\\n'
     IGNORE 11 LINES;
  ";
?>

Requête MySQL avec phpMyAdmin :

Code :

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

1
2
3
4
5
6
7
8
 
LOAD DATA INFILE 'D:\\xampp\\htdocs\\MonSite\\MonFichier.csv
     INTO TABLE `t_GestionSites`
     FIELDS TERMINATED BY ';'
     ENCLOSED BY '\\'
     ESCAPED BY '\\'
     LINES TERMINATED BY '\n'
     IGNORE 11 LINES;

Monfichier.csv contient un champs pouvant contenir des "\" comme "blabla\bloblo\bli\blu\blu\"
Tous les champs sont séparés par des ";"

De plus, je rencontre aussi un pb avec le dernier champs, il semblerait qu'il contienne un caractère caché mais je ne sais pas quoi.

Merci pour votre aide.
Là je sèche complètement.

[hello29]

Ce serait plus facile si tu nous donnais le message d'erreur que tu obtiens lorsque tu exécutes ta requêtes avec PHP

[Korben-Dallas]

code PHP :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
...
...
...
  $RequeteInjectionGestionSite = "
LOAD DATA INFILE 'D:\\xampp\\htdocs\\MonSite\\UpLoad\\MonFichier.csv'
     INTO TABLE `t_GestionSites`
     FIELDS TERMINATED BY ';'
     ENCLOSED BY '\\'
     ESCAPED BY '\\'
     LINES TERMINATED BY '\\n'
     IGNORE 11 LINES
  ";
...
...
...
...
              $ResultatRequeteInjectionGestionSite = mysql_query($RequeteInjectionGestionSite) or die("Erreur dans la requÛte : " . $RequeteInjectionGestionSite);
...
...
...

Résultat :

Erreur dans la requęte : LOAD DATA INFILE 'D:\xampp\htdocs\MonSite\UpLoad\MonFichier.csv' INTO TABLE `t_GestionSites` FIELDS TERMINATED BY ';' ENCLOSED BY '\' ESCAPED BY '\' LINES TERMINATED BY '\n' IGNORE 11 LINES;

[hello29]

Code :

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

LOAD DATA INFILE 'D:\xampp\htdocs\MonSite\UpLoad\MonFichier.csv' INTO TABLE `t_GestionSites` FIELDS TERMINATED BY ';' ENCLOSED BY '\' ESCAPED BY '\' LINES TERMINATED BY '\n' IGNORE 11 LINES;

Regarde la requête que ton code PHP exécute : ce n'est pas la même que celle que tu lances avec PhpMyAdmin... Dans ton code PHP, tu as bien doublé le \ pour le \n, mais tu ne l'as pas fait pour les autres \.

Sinon, un petit conseil pour débuguer plus facilement : utilise la fonction mysql_error() :

Code :

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

$ResultatRequeteInjectionGestionSite = mysql_query($RequeteInjectionGestionSite) or die("Erreur dans la requête : " . mysql_error());

[Korben-Dallas]

bah justement si les "\" sont bien doublés.

ENCLOSED BY '\\'
ESCAPED BY '\\'

Ou alors là je ne vois pas du tout.
Sinon j'ai rajouter la fonction comme tu l'indiques et voici le résultat :

Erreur dans la requęte : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\' LINES TERMINATED BY '\n' IGNORE 11 LINES (`AdresseDebutPlag' at line 4

J'ai aussi modifié le code pour être :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
  $RequeteInjectionGestionSite = "
LOAD DATA INFILE 'D:\\xampp\\htdocs\\MonSite\\UpLoad\\MonFichier.csv'
     INTO TABLE `t_GestionSites`
     FIELDS TERMINATED BY ';'
     ENCLOSED BY '\\'
     ESCAPED BY '\\'
     LINES TERMINATED BY '\\n'
     IGNORE 11 LINES
     (`AdresseDebutPlage`, `AdresseFinPlage`, `AdresseIP_Agent`, `DNS_Agent`, `SiteComplet`, `Direction`);
  ";

[Korben-Dallas]

bon j'ai fini par trouver le pb et en effet il manquait des "\" j'ai donc corrigé celà.
Par contre il me reste toujours des pb avec l'import.
J'ai l'impression qu'il y a des caractères cachés dans le dernier champs après la valeur réelle.
Comment résoudre ceci svp ?
Merci

[misthuko]

Hello,

J'ai eu le meme probleme il y a peu. J'ai termine mon fichier csv par un '\n' et depuis je le fais tout le temps. Je sais pas trop si ca t'aide.

[Korben-Dallas]

En fait le fichier csv est généré par un logiciel tel que Excel ou autre.
De plus ce n'est pas à la fin du fichier que je rencontre le pb mais bien au niveau du dernier champs, lors de l'import il y a des caractères cachés qui se sont rajoutés mais je ne sais pas lesquels.
En effet, si je fais une recherche comme ceci :

Code :

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

1
2
3
4
5
6
7
 
SELECT 
     *
FROM
    MaTable
WHERE
    DernierChamp LIKE 'BlaBlaBla'

Le résultat est "Aucun résultat retourné"

Par contre si je fais une recherche comme ceci :

Code :

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

1
2
3
4
5
6
7
 
SELECT 
     *
FROM
    MaTable
WHERE
    DernierChamp LIKE 'BlaBlaBla%'

Le résultat est bien le résultat attendu, tous les champs sont sélectionnés. Et ceci juste en étandant la recherche à la fin du DernierChamp.

Que faire ?
Merci pour votre aide.

[Korben-Dallas]

Bonjour,

Personne pour m'aider à résoudre ce pb de caractère caché qui est des plus embêtant ?
Je sais qu'il y a un caractère qui s'est caché lors de l'import mais je ne sais pas quoi ni comment supprimer ce caractère indésirable.
Merci encore pour votre aide.

[CinePhil]

Si le caractère caché existe pour toutes les lignes, fais une requête UPDATE qui ne va garder que du premier à l'avant dernier caractère de gauche :

Code :

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

1
2
UPDATE ma_table
SET ma_colonne = LEFT(ma_colonne, LENGTH(ma_colonne) - 1)

[Korben-Dallas]

Merci
C'est ce que j'ai fait avec la requete suivante mais je ne trouvais pas ça propre car il ne faut pas supprimer à chaque fois le dernier caractère sinon le champs se videra et comme il n'est pas possible de savoir à quel moment l'import se fait puisque ce sont des utilisateurs différents qui feront cette imports via formulaire (envoi de différents fichiers selon le profile de l'utilisateur directement sur le serveur et injection automatique dans la BDD). C'est pour celà que je préférai rechercher ce fameux caractère génant et le supprimer.

Code :

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

1
2
3
 
  UPDATE `t_gestionsites` 
  SET `Champs` = SUBSTRING(`Champs`, 1, (CHARACTER_LENGTH(Champs)-1))

[CinePhil]

Essaie de capturer ce caractère fantôme avec la fonction ASCII :

Code :

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

1
2
SELECT ASCII(RIGHT(ma_colonne, 1)) AS code_dernier_caractere
FROM ma_table

Ensuite tu peux agrémenter la requête UPDATE d'un WHERE sur ce code ASCII :

Code :

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

1
2
3
UPDATE ma_table
SET ma_colonne = LEFT(ma_colonne, LENGTH(ma_colonne) - 1)
WHERE ASCII(RIGHT(ma_colonne, 1)) = -- le code précédemment trouvé

[Korben-Dallas]

Merci pour l'info.
Voici ce que la requête suivante (la tienne adaptée) me donne :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
SELECT 
     CHARACTER_LENGTH( `Champs` ) AS Nbre_Caracteres,
     '',
     ASCII( RIGHT( `Champs` , 1 ) ) AS Code_Dernier_Caractere, 
     RIGHT( `Champs` , 1 ) AS Dernier_Caractere,
     '',
     ASCII( RIGHT( `Champs` , 2 ) ) AS Code_Avant_Dernier_Caractere,
     RIGHT( `Champs` , 2 ) AS Avant_Dernier_Caractere
FROM 
     t_gestionsites

Nbre_Caracteres | Code_Dernier_Caractere | Dernier_Caractere | Code_Avant_Dernier_Caractere | Avant_Dernier_Caractere
14 | 13 | | 84 | T
14 | 13 | | 84 | T
14 | 13 | | 84 | T
14 | 13 | | 84 | T

[CinePhil]

Et donc le caractère est le retour charriot - CHRS(13).

Dans la doc MySQL, on peut lire ceci :

Note

If you have generated the text file on a Windows system, you might have to use LINES TERMINATED BY '\r\n' to read the file properly, because Windows programs typically use two characters as a line terminator. Some programs, such as WordPad, might use \r as a line terminator when writing files. To read such files, use LINES TERMINATED BY '\r'.

Donc dans ta requête, remplace \n par \r\n au paramètre LINES TERMINATED BY.

[Korben-Dallas]

OK Merci
Le pb est en effet maintenant résolu (tout du moins pour cette partie) car il reste encore un petit qq chose que je ne comprends pas vraiment.
En fait dans ma page php, lorsque le formulaire est validé afin d'envoyer le fichier vers le serveur et l'injecter dans la BDD, j'ai fait une requête qui supprime toutes les données liées au profile utilisateur avant l'import (ceci afin d'avoir les données toujours à jour)
Mais je remarque aussi que lorsque la table est vide j'ai bien les données telles qu'elles sont dans le fichier ainsi importé.
Par contre lorsque je renvoi ce même fichier pour tester la mise à jour de la table (suppression et injection) alors là les données ne sont plus comme dans le fichiers, elles se retrouve totalement dans le désordre et du coup il est très difficile de contrôler que les données injectées soient bien celles du fichier (tout du moins dans la phase de test puisqu'on sait que dans la BDD il n'est pas obligatoire que les données soient exactement dans le fichier)
Ceci pour contrôler en qq sorte, là j'en perds mon latin.
En injectant 2 fois le même fichier, je devrais me retrouver avec exactement les mêmes données à chaque fois (en ayant supprimé les données entre chaque import) mais là non. Que se passe -t-il du coup ?

[CinePhil]

J'ai un sac de billes. Je te donne une bille et je te demande de la mettre dans le sac. Je ferme le sac, je l'ouvre et je te demande de retrouver la bille.
Impossible !

Une table SQL est un ensemble non ordonné, comme un sac de billes !

L'ordre éventuel ne peut être donné à coup sûr que par requête comprenant une instruction ORDER BY.

[Korben-Dallas]

OK je vois bien l'image mais j'ai un tuyaux dans lequel je mets mes billes.
Elles vont toutes être dans l'ordre auquel je les rentre. On est d'accord ?
Maintenant je vide mon tuyaux en enlevant les billes les unes après les autres.
Ensuite je remets les billes exactement dans le même ordre que précédemment, elles devraient se retrouver dans le tuyaux exactement à la même place. Non ?

Et plus surprenant, j'ai rempli une première fois mon tuyaux avec mes billes. Maintenant j'enlève toutes mes billes d'un coup.
Le tuyaux est donc totalement vidé.
Je remets mes billes exactement dans le même ordre qu'elles ont été mises la première fois. Et bien là, lorsque je vérifie le tuyaux, les billes sont exactement à la même place que la première fois (avant de vider le tuyaux).

En gros, c'est comme si le DELETE n'avait pas la même action que le TRUNCATE.
Si je fais un TRUNCATE de la table (elle se vide totalement et l'import se fait dans un certain ordre)
Si je fais un DELETE de tous les enregistrements, la table se vide totalement aussi mais l'import se fait totalement dans le désordre.
C'est ça que je ne comprends pas trop, surtout que l'import est identique, on prend un fichier et on lit les champs un par un pour les injecter dans la table.

[CinePhil]

DELETE supprime des lignes d'une table.
TRUNCATE supprime la table puis la recrée à vide. Ce n'est donc plus la même table physique, elle ne sera pas stockée forcément au même endroit.

Par contre, d'après la doc, TRUNCATE est équivalent à DELETE si c'est une table InnoDB qui est impactée par des contraintes de clé étrangère car alors les lignes sont supprimées une à une pour vérifier s'il n'y a pas des lignes en cascade à supprimer.

[Korben-Dallas]

HA OK je comprends un peu mieux.
En tout cas, c'est clair que c'est vraiement tout un métier les bases de données.
Et merci pour ton aide et les infos, c'est cool.