Problème de maj/min dans une requête

[ruff15]

Bonjour,
Pourquoi ces deux requêtes sont différentes dans la mesure où l'une me retourne un enregistrement de ma table et l'autre non?
SELECT * FROM ma_table WHERE mon_champ = 'TOTO'
SELECT * FROM ma_table WHERE mon_champ = 'toto'

Merci

[Hédhili Jaïdane]

Bonjour.

Cela me semble normal dans la mesure où 'TOTO' et 'toto' sont des constantes texte alpha (literal), donc il n'y a pas de conversion maj/min. Par contre quand il s'agit d'instructions, de commande, de variables, etc... le compilateur, l'interpreteur, etc..., fait la conversion.

[ruff15]

Je suis bien d'accord avec vous. Mais alors pourquoi pour d'autres bases teslles que MySql ou SQL Server il n'y a aucune différence entre les deux requêtes?

[Hédhili Jaïdane]

Je ne sais et franchement cela me semble curieux pour une constante ???
Peut être s'agissait-il d'une contante servant à la comparaison ou recherche de chaine en ne tenant pas compte de la casse, auquel cas...

HJ

[Mercure]

SELECT * FROM ma_table WHERE UPPER(mon_champ) = 'TOTO'
SELECT * FROM ma_table WHERE LOWER(mon_champ) = 'toto'

LOWER & UPPER, ça va marcher mais c'est à éviter car couteux en matière de temps de traitement paraît-il.

pourquoi pour d'autres bases teslles que MySql ou SQL Server il n'y a aucune différence

Faut demander à M$ alors...

[ruff15]

Bon je vais détailler, peut-être cela vous éclairera davantage.
J'ai une application développée en J2EE (Websphere, Struts-layout, EJB, ...) qui utilise comme base DB2. J'ai importé depuis une autre base (SQL Server) des tables de paramètres comme par exemple (Pays, Devises, etc...)

Prenons l'exemple de la table Pays(Code, Libellé), nous avons les données suivantes :
FR - France
US - USA
ES - Espagne ...

Au niveau d'un écran de saisie E1, j'ai un champ que j'appelle Pays Origine. Il est sur deux positions donc il ne peut contenir des lettres comme Fr, Us etc...
L'utilisateur peut saisir des majuscules ou des minuscules dans le champ. D'ou mon problème posé car il ya un controle d'intégrité qui est géré par le conteneur EJB donc je ne peux pas accéder à cette requête. Si l'utilisateur saisit 'Fr', le controle d'intégrité va renvoyé une erreur car en base c'est 'FR' qui existe comme clé.
Or sous SQL Server, MySql, il ne fait pas de différence entre la casse.

En conclusion, sous DB2, 'FR', 'fr', 'Fr', 'fR' sont quatres pays différents tandis que sous Sql Server ou autre non

[Hédhili Jaïdane]

Salut.

Je n'ai pas une grande pratique de SQL mais AMHA tu devrais regarder du côté de la définition de la contrainte référentielle elle même et de la clé de référence qui assure le lien avec la clé de la table parente. Je ne sais pas si tu peux définir cette clé comme UPPER(CODE_PAYS).

C'est juste une piste à explorer

Cordialement
Hédhili Jaïdane
- - - - - - - - -

[ruff15]

Salut,
Tout d'abord je voudrais vous remercier pour votre disponibilité. Je crois bien qu'il m'est impossible de gérer ça au niveau de la base DB2.
De plus mes requêtes de sélection sont gérées par le conteneur EJB. Donc c'est réalisé en background, je n'ai aucune visibilité là dessus.
Alors à moins d'une lumière venue de l'un de vous, je crois que je vais devoir appliquer un style CSS (text-transform: uppercase; ) sur les champs de mes écrans (bonjour la charge de travail)...

[jab]

Pour info mais cela ne résoud pas ton problème: http://www-128.ibm.com/developerwork...402greenstein/

[alex.]

Pour Mercure,

On doit pouvoir coder SELECT * FROM ma_table WHERE mon_champ = UPPER('ToTo') et le prédicat est (pas testé) indexable.

D'une manière générale, il faut essayer de faire porter la fonction sur la chaïne de caractères. C'était un "tip" sur db2 V7, typiquement sur un cast de type de données mais en V8, ça semble de plus en plus intégrer dans l'optimiseur.

Alex.