Problème de requète sur un champ de type string

Version imprimable

Bonjour à la communauté de developpez.com

Je suis actuellement confronté à un problème très bizarre sur SQL SERVER (version 2008 R2, 10.50.2500.0).
Je m'explique. Dans une des tables SQL SERVER, j' ai un champ de type string qui renseigne un nom : "S. BICKLEY".

Alors, si Je fais une requête du type :
Code:

1 2 3 4 SELECT nom_champ FROM Nom_table WHERE nom_champ='S. BICKLEY' --> rien SELECT nom_champ FROM Nom_table WHERE nom_champ like '%S. BICKLEY%' --> ok ca s'affiche SELECT nom_champ FROM Nom_table WHERE nom_champ like '%S. BICKLEY'--> rien SELECT nom_champ FROM Nom_table WHERE nom_champ like 'S. BICKLEY%' --> ok ca s'affiche
Si je fais un update avec une requete du type :
UPDATE nom_table SET nom_champ='S. BICKLEY' WHERE nom_champ like '%S. BICKLEY%'
tout refonctionne normalement... ouf ! mais bof quand même ;-)

Bref, vous l'aurez compris, c'est comme si ce qui est écrit dans ma table n' est pas vraiment ce qui est écrit ...
Et ce problème n' apparait qu'avec ce nom. J' ai vérifié 50 fois : il n' y a pas d'espace après 'BICKLEY' ni avant 'S.' ...
Je précise que je vois bien l'information écrite dans ma table avec Microsoft SQL Server Management.

Est ce que ce ne pourrait pas venir d'une différence de culture entre mon langage de programmation de l'application qui écrit dans la base
et le moteur SQLSERVER dans sa configuration ?

Ou peut être un problème dans la conversion de caractères ASCII ?
Peut il y avoir une différence entre l'information qui est écrit dans le fichier binaire de donnée SQL ? apparemment oui

J' avoue que je sèche un peu la...

Hervé

22/09/2016, 11h24
François DORIN

Bonjour,

Il aurai été intéressant d'afficher la longueur de la chaîne. A priori, vu les tests effectués, il s'agit d'un ou plusieurs caractères qui se situent après la chaîne. Sachant que tous les caractères ne sont pas imprimables et donc visibles !!
Tu aurais aussi pu convertir la chaine en hexa pour voir le contenu exact.

Je ne pense pas que ce soit un problème lié à la culture, sinon tes différents tests auraient tous été négatifs.

Bonjour,

Je suppose que votre colonne est de type varchar (donc elle utilise l'ASCII), et que la taille maximale qu'autorise ce type pour cette colonne est d'au plus 8000 caractères.
Pour vous assurer que la chaîne ne contient pas de caractères non imprimables, il faut vérifier que leur code ASCII n'est pas compris entre 0 et 31.
Pour ce faire, on peut créer une petite fonction de table en ligne :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 CREATE FUNCTION f_string_characters_exploder (@_string varchar(max)) RETURNS TABLE WITH SCHEMABINDING AS RETURN ( WITH N AS(SELECT NULL AS v UNION ALL SELECT NULL) , N1 AS (SELECT A.v FROM N AS A CROSS JOIN N AS B) , N2 AS (SELECT A.v FROM N1 AS A CROSS JOIN N1 AS B) , N3 AS (SELECT A.v FROM N2 AS A CROSS JOIN N2 AS B) , N4 AS (SELECT A.v FROM N3 AS A CROSS JOIN N3 AS B) , RN AS ( SELECT ROW_NUMBER() OVER(ORDER BY (SELECT NULL)) AS rn FROM N4 ) SELECT SUBSTRING(@_string, RN.rn, 1) AS character , ASCII(SUBSTRING(@_string, RN.rn, 1)) AS character_ASCII_code FROM RN WHERE rn BETWEEN 1 AND LEN(@_string) )
Je disais 8000 caractères parce que si vous êtes en varchar(max), il vaut mieux créer une table utilitaire de nombres : la requête, une fois la fonction qui précède adaptée, en sera beaucoup plus performante.
Code:

1 2 3 4 5 6 SELECT TEC.une_chaine , SCE.character , SCE.character_ASCII_code , CASE WHEN SCE.character_ASCII_code BETWEEN 0 AND 31 THEN CAST(0 AS bit) ELSE CAST(1 AS bit) END AS is_printable_character FROM dbo.test_explosion_chaine AS TEC CROSS APPLY dbo.f_string_characters_exploder(TEC.une_chaine) AS SCE
La colonne is_printable_character vous indique ce que vous cherchez. N'hésitez pas à rajouter une clause WHERE à la requête pour filtrer les lignes d'intérêt.

@++ ;)

Citation:

Envoyé par herve4

Bonjour à la communauté de developpez.com

Je suis actuellement confronté à un problème très bizarre sur SQL SERVER (version 2008 R2, 10.50.2500.0).
Je m'explique. Dans une des tables SQL SERVER, j' ai un champ de type string qui renseigne un nom : "S. BICKLEY".

Le type "string" n'existe pas en SQL. Les chaines de caractères sont représentées par 6 types SQL différents :

CHAR(n)
VARCHAR(n)
VARCHAR(max)
NCHAR(n)
NVARCHAR(n)
NVARCHAR(max)

n étant la longueur maximale.
Sans cette information impossible de vous aider.
En effet le comportement des requêtes SQL et notamment des fonctions de traitement de chaines comme LIKE diffère en fonction de ces types...
Citation:
Alors, si Je fais une requête du type :
Code:

1 2 3 4 SELECT nom_champ FROM Nom_table WHERE nom_champ='S. BICKLEY' --> rien SELECT nom_champ FROM Nom_table WHERE nom_champ like '%S. BICKLEY%' --> ok ca s'affiche SELECT nom_champ FROM Nom_table WHERE nom_champ like '%S. BICKLEY'--> rien SELECT nom_champ FROM Nom_table WHERE nom_champ like 'S. BICKLEY%' --> ok ca s'affiche
Si je fais un update avec une requete du type :
UPDATE nom_table SET nom_champ='S. BICKLEY' WHERE nom_champ like '%S. BICKLEY%'
tout refonctionne normalement... ouf ! mais bof quand même ;-)
Compte tenu de ce que vous constatez je parierais sur un VARCHAR avec des blancs en queue de chaine.

Citation:

Bref, vous l'aurez compris, c'est comme si ce qui est écrit dans ma table n' est pas vraiment ce qui est écrit ...
Et ce problème n' apparait qu'avec ce nom. J' ai vérifié 50 fois : il n' y a pas d'espace après 'BICKLEY' ni avant 'S.' ...
Je précise que je vois bien l'information écrite dans ma table avec Microsoft SQL Server Management.

Est ce que ce ne pourrait pas venir d'une différence de culture entre mon langage de programmation de l'application qui écrit dans la base
et le moteur SQLSERVER dans sa configuration ?

Ou peut être un problème dans la conversion de caractères ASCII ?
Peut il y avoir une différence entre l'information qui est écrit dans le fichier binaire de donnée SQL ? apparemment oui

J' avoue que je sèche un peu la...

Hervé

A +