[RESOLU] Problème avec Load Data

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : [RESOLU] Problème avec Load Data

Re: [RESOLU] Problème avec Load Data

par BaLiSTiK » 14 oct. 2013, 15:48

Ma solution :
SET @OLD_SQL_MODE = @@SQL_MODE;
SET SQL_MODE = 'NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
//Requête LOAD DATA INFILE...
SET @@SQL_MODE = @OLD_SQL_MODE;

Re: Problème avec Load Data

par BaLiSTiK » 10 oct. 2013, 09:30

Après acharnement, je pense avoir trouvé le problème, ça viendrait du SQL_MODE.
SI je lance cette requête :
SELECT @@GLOBAL.sql_mode;
J'ai en réponse :
+----------------------------------------------------------------+
| @@GLOBAL.sql_mode |
+----------------------------------------------------------------+
| STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+----------------------------------------------------------------+
1 row in set (0.00 sec)
En lisant la doc, je suis tombé sur ça :
- STRICT_TRANS_TABLES
Si une valeur n'a pas pu être insérée dans une table transactionnelle sans modification, la commande est annulée. Pour une table non-transactionnelle, la commande est annulée si cela survient dans une ligne unique ou dans la première ligne d'une insertion multiple.
ça tombe dans mon cas. Du coup, je voudrai changer la valeur du SQL_MODE mais dois-je lui ajouter la valeur 'TRADITIONAL' à la place de 'STRICT_TRANS_TABLES' ou alors l'ajouter à la suite ?

Problème avec Load Data

par BaLiSTiK » 09 oct. 2013, 13:44

Bonjour,

Je rencontre un soucis assez spécial qui me bloque et me prend la tête depuis hier (rien que ça) !
Afin d'insérer rapidement des données depuis un CSV, j'utilise une requête de type "Load Data Local Infile...". Le problème n'est pas la requête en elle même car elle fonctionne mais plutôt le fichier CSV. En voulant tester la réaction de MySQL si celui-ci est confronté à un fichier contenant de mauvaises données, je me suis retrouvé avec ces résultats :
- Si la première ligne de mon fichier CSV est incorrecte (par exemple données d'un champ trop long), la requête n'est pas exécutée
- Par contre, si la 1ère ligne est correcte, mais que des erreurs apparaissent sur d'autres lignes, la requête s’exécute bien et l'insertion se fait (en tronquant les champs trop long).

Pourquoi ce résultat différent selon le bon format ou non de la première ligne ? Je ne trouve aucune réponse :(

Pour info : insertion en table de type MyIsam, et concernant le csv, les champs sont séparés par des ',' et chaque fin de ligne par un saut de ligne.

Merci d'avance.