Comment effectuer une comparaison LIKE insensible à la casse ?

[Hervé Saladin]

Bonjour,
j'ai une requête avec un like que je voudrais rendre insensible à la casse :

Code :

1
2
3
SELECT DISTINCT id_document, identifiant_meta 
FROM vue_moteur_recherche 
WHERE (identifiant_meta = 'format' AND valeur_meta LIKE '%word%') )

Vous aurez compris que je voudrais que ma requête me retourne les enregistrements dont le champ valeur_meta contient Word ou word indiférament.
Or, il semble que chez moi, like soit sensible à la casse (ce qui est bizzare, car au cours de mes recherches j'ai lu plusieures fois qu'il était censé être insensible).
J'ai essayé de jouer avec les fonction UPPER() ou LOWER() de la manière suivante :

Code :

1
2
3
SELECT DISTINCT id_document, identifiant_meta 
FROM vue_moteur_recherche 
WHERE (identifiant_meta = 'format' AND UPPER(valeur_meta) LIKE UPPER('%word%')) )

=> même résultat, la requête est sensible à la casse ... c'est incompréhensible on dirait que les fonctions upper et lower n'ont strictement aucun effet (est-ce à cause du like ou des jokers ?)
J'en viens à me demander si ce n'est pas un problème de config de mon serveur (mais lequel ?).

Y'a t'il une astuce miracle en SQL ?
Dois-je faire un réglage sur mysql ?

Je précise que je travaille sur MySQL 5 sous windows, les champs interrogés par ma requete sont issus d'une vue, ils sont dans leur table d'origine de type varchar et d'interclassement latin1_swedish_ci

Merci d'avance aux pros de MySQL du forum

[Maximilian]

Bonjour,

Tu pourrais utiliser BINARY. Cf http://www.developpez.net/forums/sho...ighlight=casse

D'autres posts en parlent, fais une recherche sur "casse" dans le forum.

[Hervé Saladin]

OK, merci de ta réponse.
Je sais pas si j'ai bien compris, mais il me semble que BINARY est censé rendre sensible une comparaison qui à la base ne l'est pas (c'est bien ça ?)
Or, moi c'est exactement le contraire que je veux faire : sensible >>> insensible.

Pour ce qui est de la recherche sur le forum, je l'avais déja faite avant de poster, et effectivement on y parle de pleins de problèmes liés à la casse (pas étonnant) mais je n'ai réussi à trouver aucune info utile concernant mon problème qui est très spécifique et que j'ai l'impression d'être le seul à avoir ...

En continuant à m'acharner sur mon SQL, j'ai découvert que ce problème semble lié au fait que ma requête porte sur une vue :
en effet, en faisant une requête du même type (avec un like), sur le même champ, mais portant sur la table d'origine au lieu de porter sur la vue, ça marche bien, sans problème de casse ...

Quelqu'un sait comment rendre ma vue insensible à la casse ?
Une config serveur ? une clause particuliere lors de la création de la vue ? ...

Merci d'avance

[jp_rennes]

Je te confirme que par défaut le like est insensible à la casse.
Va voir http://dev.mysql.com/doc/refman/5.0/...nsitivity.html

[Hervé Saladin]

Oui, c'est ce qui m'étonne le plus, car je n'ai pas modifié la config par défaut de mysql.
Je n'ai pas réussi à élucider ce mystère, mais j'ai finalement pu m'en tirer grâce à LOWER()
Quand je faisais cela, ça ne marchait pas (enfin, du moins ça tenait compte de la casse) :

Code :

1
2
3
SELECT DISTINCT id_document, identifiant_meta 
FROM vue_moteur_recherche 
WHERE (identifiant_meta = 'format' AND LOWER(valeur_meta) LIKE LOWER('%Word%')) )

Donc à la place, j'ai re-créé la vue en mettant des LOWER() sur tous les champs que je sélectionne lors de la création de la vue.
Puis, lorsque je fais ma requête sur ma vue, je réduis 'Word' en minuscule (en PHP) avant d'envoyer la requete.

Et comme ça, ça marche

Mais bon, c'est du bricolage ...

[Sivrît]

Peut-être que le passage par une vue fait perdre le status de chaine de caractères... en tout cas ça ressemble pas mal à un bug sur les vues si leur comportement diffère de celui des tables.

[Hervé Saladin]

Envoyé par Sivrît

Peut-être que le passage par une vue fait perdre le status de chaine de caractères...

C'est ce que je me suis dit aussi en constatant ce comportement, en tout cas ça en a tout l'air ...

Envoyé par Sivrît

en tout cas ça ressemble pas mal à un bug sur les vues si leur comportement diffère de celui des tables

Là personellement, je ne m'y connais pas suffisament en MySQL pour pouvoir dire si c'est un bug ou un problème de config ou si c'est normal.