Discussion :

[Trocmuch]

Bonjour à tous et merci de me lire.

Je m'arrache les cheveux sur le problème suivant.

j'ai une table de la forme : id nom prenom surnom

J'établis une requête SELECT * FROM ma table WHERE surnom='valeur';

le retour est vide.

par contre SELECT * FROM ma table me retourne bien toutes les valeurs de la colonne surnom.

Quelqu'un aurait-il une idée ?

Merci d'avance

J'ajoute que ma table est une importation d'un fichier csv;
le problème se situe probablement là puisque lorsque je crée à la main le même fichier tout fonctionne normalement.

[al1_24]

N'y aurait-il pas des espaces ou des caractères cachés dans ta colonne ?
Essaye ainsi :

Code :

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

1
2
SELECT * FROM ma table WHERE TRIM(surnom) = 'valeur';
SELECT * FROM ma table WHERE surnom LIKE 'valeur%';

[Artemus24]

Salut Trocmuch.

Vu qu'il n'y a pas au moins un exemple, on ne peut qu’émettre des hypothèses.

1) avez-vous utilisé "char" ou varchar" comme type de la colonne "surnom" ?

1-a) Admettons que vous avez utilisez char(10) et que le surnom soit "bob".
Cela sera stocké de la façon suivante "bob ", c'est-à-dire complété avec sept espaces.
si vous faites "where surnom = 'bob'", le test ne fonctionnera pas.

dans ce cas, il faut plutôt écrite : "where surnom like 'bob%'"

1-b) dans le cas de varchar, le problème ne se pose pas car la valeur ne sera pas complété par des espaces.
De ce fait, "where surnom = 'bob'" doit fonctionner.

2) quel est le charset utilisé dans votre base de données.
Il est fort probable que vous avez utilisé le "UTF8".
Etes-vous certain que dans le script, vous utilisez le même charset ?
A l'affichage, vous ne verrez pas de différence, car un "é" en windows-1252 ou en utf8 s'affiche de la même façon. Tandis que le code du caractère n'est pas le même.

3) et en ce qui concerne le transfert entre le SGBDR MySql et votre script ?
N'avez-vous pas oubliez de faire un "set names=UTF8 ?

4) quel type de collation avez-vous utilisez ?
Admettons que surnom soit "béa" pour "béatrice".
Qu'est-ce qui ce passe si vous tapez "where surnom = 'bea'" ?
Si vous avez utilisez par exemple "utf8_general_ci" la casse sera insensible, et donc le test fonctionnera.
Tandis qu'avec "utf8_bin" le test ne fonctionnera pas.

Le mieux est de nous donner le descriptif de votre base et de votre table en mettant en avant le charset et le collate.
Ainsi qu'un exemple où vous avez un problème ?
Donnez-nous aussi le charset qui a été utilisé dans votre fichier excel ?

@+

[Trocmuch]

Bonjour et merci de vos réponses,

J'ai essayé TRIM, mais cela n'apporte rien.
Par contre LIKE fonctionne.

voici le détail de mes opérations:
Je parts d'un fichier excel avec trois colonnes.
Les deux premières n'ont aucun enregistrement vide.
La troisième oui.( celle que je nomme surnon)

J'ai transformé mon excel en csv . Ne connaissant pas l'encodage, j'ai repris ce même fichier dans un traitement de texte pour l'encoder ou le réencoder en utf8.
Je l'ai incorporé dans ma table via phpmyadmin en utilisant le fonction LOAD DATA INFILE ...
Ma base, ma table, mon script sont tous en utf8. La base et la table utilisent general_ci.

Une requête SELECT * FROM base m'envoie bien la totalité de mes enregistrements y compris ceux de la troisième colonne.
Une requête SELECT surnon FROM base WHERE nom (ou prenom)='valeur' fonctionne et me donne bien la valeur de surnon.
Je remarque par contre que à l'affichage via var_dump, la longueur affichée du string de surnom excède sa valeur réelle de 1.
SELECT * FROM base WHERE surnom='valeur' me renvoie un array vide et ce sur toutes les valeurs de where.

J'ai remanié mon fichier excel en complétant tous les champs de la troisième colonne et j'ai transféré ces nouvelles donnees dans la table .
Cette fois-ci le fonctionnement est redevenu normal.

Ces explications vous font-elles entrevoir une explication de cette apparente anomalie ?

Cordialement


J'ai observé que

[Artemus24]

Salut Trocmuch.

Ces explications vous font-elles entrevoir une explication de cette apparente anomalie ?

Non, car vous n'avez pas répondu à mes questions :

Le mieux est de nous donner le descriptif de votre base et de votre table en mettant en avant le charset et le collate.
Ainsi qu'un exemple où vous avez un problème ?
Donnez-nous aussi le charset qui a été utilisé dans votre fichier excel ?

@+

[aieeeuuuuu]

1-a) Admettons que vous avez utilisez char(10) et que le surnom soit "bob".
Cela sera stocké de la façon suivante "bob ", c'est-à-dire complété avec sept espaces.
si vous faites "where surnom = 'bob'", le test ne fonctionnera pas.

Si, le test fonctionnera.
Dans le cas de comparaison de chaines de tailles différentes, la plus courte est complétée à droite par des espaces.

Il doit en effet y avoir des caractères non visibles en fin de chaine (dûs à l'importation), mais il ne s'agit pas d'espaces. probablement des retours chariot.

[Trocmuch]

J'ai enfin pu résoudre mon problème qui se situait au niveau de l'importation via la commande LOAD DATA INFILE ...

La ligne " LINE TERMINATED BY \n"" s'est révélée insuffisante. J'ai dû indiquer \r\n et le caractère supplémentaire(invisible) des valeurs importées a été supprimé.

Merci à tous pour votre implication.