Discussion :

[guidav]

Bonjour

J'ai une table contenant des codes de devises de type AUD, CAD, EUR, USD, ZAR en collation CS_AI
Observez bien le résultats des requêtes suivantes :
select * from table where devise like '[ABC]%' : AUD, CAD
select * from table where devise like '[ACZ]%' : AUD, CAD
select * from table where devise like '[AZC]%' : AUD
select * from table where devise like '[A-Y]%' : AUD, CAD, EUR, USD
select * from table where devise like '[A-Z]%' : rien
select * from table where devise like '[Z]%' : ZAR

mais
select * from table where devise like '[A-Z]%' COLLATE CS_AS : tout

Quelqu'un saurait-il pourquoi le Z pose problème dans la requête en CS_AI ?

Que faire pour résoudre ce problème ?

[SQLpro]

Quelle est la collation de la colonne devise dans la table ?

C'est cela qui te guidera vers la solution.

De plus la collation CS_AS n'existe pas. Il faut la langue !

A +

[guidav]

Merci de ta réponse, et au temps pour moi, j'ai été un peu rapide dans mon exposé.
La table (et le champ) sont en Latin1_General_CI_AS, et la requête fonctionne si on précise COLLATE Latin1_General_CS_AS

Ce qui me surprend, c'est que la lettre Z n'a pas de raison d'être sensible aux accents, si ?

[SQLpro]

C'est une problématique de classement due à la lange latine dans laquelle les accents n'existent pas....

A +

[guidav]

D'accord, mais pourquoi cela a-t-il un impact sur ma requête ? Je n'ai pas d'accents dans ma table, ni dans mes critères de requête.
En fait, j'aimerais surtout comprendre pourquoi je n'ai pas de résultat (ou des résultats tronqués) avec

select * from table where devise like '[A-Z]%' : rien
ni avec
select * from table where devise like '[AZC]%' : AUD
alors que j'en ai avec
select * from table where devise like '[A-Y]%' : AUD, CAD, EUR, USD

Se pourrait-il que le Z ait une signification particulière en Latin1_General ?

[seminoque]

J'ai fais le test suivant en remplaçant XXX successivement par :
Latin1_General_CI_AS
Latin1_General_CS_AS
Latin1_General_CI_AI
Latin1_General_CS_AI

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
create table t (d CHAR(3) collate XXX)
 
insert t (d) values ('AUD')
insert t (d) values ('CAD')
insert t (d) values ('EUR')
insert t (d) values ('USD')
insert t (d) values ('ZAR')
 
select * from t where d like '[A-Z]%' 
 
drop table t

A chaque fois, le SELECT me renvoie :

Code :

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

1
2
3
4
5
AUD
CAD
EUR
USD
ZAR

Donc pour moi, tout fonctionne très bien. Désolé mais je ne vois pas d'où cela peut venir.

________________________________
Seminoque, créateur de
http://www.bingokaz.com

[guidav]

Merci pour tes tests. Ton code renvoie bien la même chose que pour toi si le champ n'est pas indexé.

Par contre, si le champ devise est indexé (ou clé primaire), mon problème réapparaît, quelque soit la collation du champ (Latin1_General_CS_AI ou Latin1_General_CS_AS), mais ça marche en Latin1_General_BIN.

Le fait d'indexer le champ a-t-il un impact sur la collation (collation implicite, ou un truc dans le genre ?). Ou faut-il définir la collation de l'index en plus de celle du champ ?

[rudib]

Bonjour,

Intéressant, il ne s'agit pas d'un problème de collation, mais d'un problème de plan d'exécution. Si tu as un index, SQL Server choisit un seek, avec un prédicat étrange : un between A et B ... La raison pour laquelle ça marche sans index ou avec un COLLATE, c'est à cause du scan de la table (le COLLATE force le scan). Je vais investiguer pour voir d'où ça peut venir.

[rudib]

Le comportement est comme tu le décris en SQL Server 2005 RTM, par contre c'est correct en SP2. As-tu un service pack installé ?

[guidav]

Merci d'avoir cherché, c'est en effet le RTM que nous avons.
Je vais demander l'upgrade à notre admin (et allumer un cierge par la même occasion).
En attendant, la clause '[ABCDE...XYZ]%' pourra toujours servir.