2009-06-19 9 views
3

Ma requête SQL sélectionne certaines colonnes à partir d'une vue avec un champ de tri optionnel. Au fond, mon avis concaténer un certain nombre de champs dans une chaîne d'adresses, de sorte que je me retrouve avec quelque chose commePourquoi UPPER() ne fonctionne pas dans MySQL?

123 Sesame Street Birdtown 

dans la colonne d'adresse. Je veux que la recherche soit insensible à la casse (il est pas par défaut), alors j'ai essayé ceci:

SELECT * FROM BasicJobInfo WHERE UPPER(address) LIKE UPPER(searchString) 

avec searchString étant l'adresse que je veux trouver. Cependant, MySQL semble être incapable de convertir l'adresse à UpperCase - J'ai essayé simplement appeler

SELECT UPPER(address) FROM BasicJobInfo 

mais il ne change pas le cas du tout. Des pensées quant à pourquoi cela pourrait être?
Aussi, des suggestions sur la façon dont je peux faire une recherche insensible à la casse?
Merci beaucoup.

+0

Pouvez-vous inclure une version de BasicJobInfo? J'utilise Oracle, pas MySQL, mais pourrait-il être que le type de données d'origine ne supporte pas "upper", et est converti en une chaîne seulement à la sortie? – l0b0

Répondre

11

Selon le MySQL Reference Manual page on String Functions:

UPPER() est inefficace lorsqu'il est appliqué à chaînes binaires (BINARY, VARBINARY, GOUTTE).

Est-il possible votre colonne ADDRESS a une BINARY, VARBINARY ou BLOB type de données?

Si c'est le cas, vous aurez besoin de convert the Binary String to an "ordinary" string. Par exemple:

UPPER(CONVERT(ADDRESS USING latin1)) 
+0

cool, cela fonctionne - merci –

+0

Juste pour clarifier, cependant, il n'y a pas de types BINARY, VARBINARY ou BLOB - adresse est juste une concaténation d'un certain nombre de champs INT et VARCHAR, donc aucune idée pourquoi cela était nécessaire. –

0

Pourriez-vous s'il vous plaît exécuter les requêtes suivantes:

SELECT @@character_set_server, @@collation_server 

SELECT HEX(CAST(UPPER(address) AS binary)), HEX(CAST(address AS binary)) 
FROM BasicJobInfo 
+0

latin1, latin1_swedish_ci 31323320436172726F747320506572746820, 31323320436172726F747320506572746820 Ces deux dernières sont exactement les mêmes que l'autre. –

1

Cela peut provenir de problèmes d'encodage. L'exécution de comparaisons insensibles à la casse est décrite dans le appendix of the mysql help pages. Exemple de comparaison de colonnes/chaînes UTF8 insensible à la casse:

SELECT * 
FROM YourTable 
WHERE address LIKE 'searchString' COLLATE utf8_general_ci; 
Questions connexes