PDO n'est qu'une interface de connexion aux SGBD du SQL reste du SQL donc "tout fonctionne".
Après c'est a toi de savoir ce que tu va avoir comme info en retour et la pour le coup je ne suis pas sur que tu le sache (var_dump est ta meilleure amie dans ces cas ).

@+

Salut,

Juste un petit rappel concernant MySQL et la casse des caractères : http://dev.mysql.com/doc/refman/5.0/fr/ ... ivity.html

Du coup, il faut bien faire attention à utiliser les bonnes fonctions de comparaison sans quoi ça ne sert à rien ^^

++

Je suggèrerais :
1) Modifier la base pour avoir des logins normalisés : tout min/ tout maj/ maj initiale
2) Modifier le script de création de comptes pour qu'il crée des logins normalisés
3) Modifier le script de connexion de façon qu'il normalise le login saisi

Ajoutons que LIKE anglais se traduit par comme ou ressemblant à, et que "François" ressemble à "Français", mais que le like de mysql a un sens fort différent:
"François" like "Français" y est faux:
Il est
- insensible à la casse,
- prévu visiblement pour comparer avec des masques contenant des jokers :
-- like "admin%" tout ce qui commence par admin quel que soit le nombre de lettres qui suivent et quelles qu'elles soient, ..
-- like "admin_" tout ce qui commence par admin quelle que soit la lettre suivante facultative ..
-- like 'admin' doit rendre juste pour les saisies "admin", "Admin", "aDmin".... "âdmin", " soit toutes les combinaisons maj/min accentuées ou pas... mais faux pour une saisie "administrateur"
- sur mes tests dans une base de mots contenant "vélo"
-- select ... like "velo" trouve "vélo" comme like "vélo" ou like "Vélo"....
-- select ... like "velo%" trouve vélo, vélodrome.... toute la famille "vélo-"
-- select ... like "velo_" trouve vélo, vélos.
Il existe aussi un REGEXP comparaison utilisant une expression régulière.
cf http://dev.mysql.com/doc/refman/5.0/fr/ ... tions.html

donc vaut mieux utiliser WHERE champs = $champs, c'est plus precis