Discussion :

[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".

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

Code :

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

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é

[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.

[elsuket]

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 :

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

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 :

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

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.

@++

[SQLpro]

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...

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

Code :

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

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.

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 +