Discussion :

[Etanne]

Bonjour,

Dans le cas où une colonne est de type NCHAR l'utilisation de l'argument LIKE se comporte du façon différente qu'avec un CHAR. En effet les espaces de droite deviennent signifiants.

Voici un exemple :

Code :

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

1
2
3
4
5
create table matable (nom nchar(50))
 
insert into matable values ('Florian')
 
SELECT * FROM matable WHERE nom LIKE N'%Florian' OR nom LIKE '%Florian'

Le SELECT le retourna aucune ligne à cause des espaces signifiants.

Mais avec

Code :

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

SELECT * FROM matable WHERE nom LIKE N'%Florian[ ]%'

J'obtiens bien une ligne.

Ma question est simple : dans le cadre d'un NCHAR sommes nous obligés d'utiliser le pattern '%xxx[ ]%' pour régler se problème d'espace significatif, ou existe t-il une solution permettant d'utiliser LIKE '%xxx' ?

Merci !

EDIT : merci aieeeuuuuu pour la remarque => mauvais explication du problème

[aieeeuuuuu]

Bonjour,


Si vous n'utilisez pas de caractère joker, faites un égal et le problème sera réglé !

sinon vous pouvez transtyper votre littéral en NCHAR(50) pour faire votre LIKE, et le problème sera réglé également.

[Etanne]

Effectivement le égal et la solution. Mais ma question se portait sur l'utilisation du LIKE qui pouvait être comme cela aussi :

Code :

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

SELECT * FROM matable WHERE nom LIKE '%orian'

Où dans ce cas j'aurais la même problématique (pas de lignes retournées).

Et dans ce cas même CAST ne fonctionnera pas (sauf si je met à NCHAR(48)) (et la requête est vraiment casse gueule) :

Code :

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

SELECT * FROM matable WHERE nom LIKE '%' + CAST('orian' AS NCHAR(50))

Si je comprend bien, il me reste pas trop le choix du :

Code :

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

SELECT * FROM matable WHERE nom LIKE '%orian[ ]%'

Merci

[aieeeuuuuu]

Pourquoi votre colonne est-elle en NCHAR(50) et non en CHAR(50) voire en VARCHAR(50) ?
êtes dans un environnement international ?

[Etanne]

Exactement nous sommes passés sur l’Unicode pour supporter l'international.

Etanne

[Invité]

Je ne suis pas sûr d'avoir bien compris la demande mais si tu as un problème avec les espaces à droites pourquoi ne pas appliquer un RTRIM au nom :

Code :

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

update matable set nom = rtrim(nom)

Comme ça le problème est réglé. Éventuellement un trigger pour appliquer l'update sur les entrées nouvelles ou modifiées.

[aieeeuuuuu]

Exactement nous sommes passés sur l’Unicode pour supporter l'international.

Pas de CHAR(50) donc...

Mais il vous reste le NVARCHAR(50). Pourquoi votre colonne est-elle de taille fixe ? Que contient-elle ?

[Etanne]

Je suis dans le cas d'une clause WHERE avec un LIKE où il n'y a pas de joker à la fin de mon pattern.

Dans le cas de l'Unicode le fonctionnement est différent, mais si cela est documenté dans la MSDN ce changement de comportement reste intrigant pour moi et j'espérai qu'il existe un astuce pour passer cette problématique.

Etanne

[Etanne]

Pas de CHAR(50) donc...

Mais il vous reste le NVARCHAR(50). Pourquoi votre colonne est-elle de taille fixe ? Que contient-elle ?

Certaines colonnes (pas toutes) sont en NCHAR pour les raisons suivantes :

• Soit l'ancienneté du schéma et les erreurs du début où le changement est prévu pour bientôt
• Ou l'on souhaite un gain de performance (contre la fragmentation, calcul d'offset, etc.)

Concernant le NVARCHAR la MSDN indique la problématique :

When you use Unicode data (nchar or nvarchar data types) with LIKE, trailing blanks are significant; however, for non-Unicode data, trailing blanks are not significant.

Etanne

[Invité]

Concernant le NVARCHAR la MSDN indique la problématique.

Ok. Problème connu mais même pas de solution de contournement indiqué...
Ce que j'ai dit avant est donc complètement crétin. Toutes mes plus plates excuses.

[Etanne]

Il faut dire que j'avais mal embrayé la discussion donc j'accepte les excuses

Comme vous le dites (vous deux), pas d'autres solutions que le ... nom LIKE '%blabla[ ]%' ou (msdn) ... RTRIM(nom) LIKE '%blabla'

Merci !

[aieeeuuuuu]

Non, pas de meilleure solution à proposer.

Mais j'ai quand même une préférence pour celle avec RTRIM : pour la maintenance, on en comprend mieux l’intérêt. Par ailleurs, nom LIKE '%blabla[ ]%' sera vrai pour 'blabla blibli', ce qui n'est pas forcément l'effet souhaité.

Enfin, comme le pattern de la solution avec RTRIM est plus simple, la consommation CPU devrait être un peu moindre...

[Etanne]

Bien vu.. ..effectivement le '[]%' n'est pas bon.

Merci pour l'aide !