Discussion :

[trollinou]

Bonjour à tous,

Je travaille sur une version 2008 R2.

Je fais une requête dans laquelle j'ai du cyrillique mais en "dur" style :

Code :

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

1
2
3
4
5
 
(SELECT CASE CodLang 
				WHEN 'BUL' THEN CONVERT(NTEXT, 'ОСВОБОДЕНИ от ДДС по Член. 21, Алинея. 2 от ЗДДС', 0)
				ELSE '' 
			END) AS RegulatoryInformation

En fait c'est ça : 'ОСВОБОДЕНИ от ДДС по Член. 21, Алинея. 2 от ЗДДС'
Mais dans la balise, ça balise à mort !

mon souci c'est que dans ce cas, le résultat me présente tout plein de joli "?" ce qui bien évidemment ne me convient pas.
Dans le cas où le "cyrillique" provient d'un champ de la base je n'ai pas le problème.

J'ai tenté différentes façons de convertir mais rien n'y fait, j'ai même essayé le COLLATE.

Merci de votre aide, de vos pistes, de tout ce qui pourrait débloquer ma situation

[elsuket]

Bonjour,

Quelle version de SQL Server utilisez-vous ?
Si vous êtes en 2000, et que vos chaînes dépassent majoritairement les 4000 caractères alors, le choix du type ntext est justifié.

Sinon, il ne l'est pas, surtout si vous êtes sous SQL Server 2005 ou 2008.
En effet depuis la version 2005, on peut utiliser le type nvarchar(max) pour stocker jusqu'à 1 milliard de caractères.
D'autre part la manipulation des chaînes en est grandement simplifiée (utilisation directe de SUBSTRING() par exemple, ...), et les types text, ntext (et image remplacé par varbinary(max)) sont donc obsolètes depuis SQL Server 2005.

Dans tous les cas, si vos chaînes font majoritairement beaucoup moins que 4000 caractères, alors utilisez le type nvarchar dès lors que vous souhaitez stocker des caractères non-latins (ceux-ci requièrent l'Unicode, qui occupe deux octets par caractères, alors que les caractères latins sont entièrement gérés par ASCII, qui ne consomme qu'un octet par caractère).

Je pense que donc votre colonne est en varchar, ce qui fait que vous obtenez les points d'interrogation à l'affichage : vous passez de l'Unicode, mais varchar stocke en ASCII.

La collation et la clause COLLATE vous permettent de spécifier un classement (voir l'article de SQLPro sur le sujet), pas la façon dont les caractères doivent être stockés

Vous pouvez donc tout à fait, dans la même colonne, avoir du Russe, du Français, de l'Anglais, de l'Espagnol, de l'Arabe, du Chinois, du Thaï et j'en passe, et utiliser un classement / une collation Japonaise ...
Si vous faites un ORDER BY, suivant la collation, il est possible que vous obteniez un classement différent

@++

[trollinou]

Bonjour,

Tout d'abord merci de votre réponse.

Je m'aperçois que j'ai été un peu fouilli dans les infos que j'ai fournit.

Ma version : 2008 R2 - 64 bits

Le contexte : Je dois générer un fichier XML depuis une requête. Cette requête, qui peut servir de multiple façon au niveau international, doit me permettre de récupérer un jeu d'enregistrement pour générer des factures.

Dans ce jeu d'enregistrement, il existe une constante pour un pays donné (La Bulgarie pour ne pas le cité : 'ОСВОБОДЕНИ от ДДС по Член. 21, Алинея. 2 от ЗДДС') ne provient pas de la base de donnée et n'a pas vocation à y séjourner.

Ce que j'ai tenté de faire :
- Conversion en différent type : nvarchar, varchar, ntext
- Utilisation de la collation ; en désespoir de cause (tout en sachant qu'il y avait peu de chance de réussite, voire pas du tout )

Résultat :
Tout les caractères cyrillique provenant de la base ne posent aucuns problèmes, seule cette constante indiquée en dur dans la requête pose problème.

Vàlà

merci encore

[trollinou]

Re

Bon j'ai contourné le problème ne créant une table, ce que je ne souhaitais pas faire au départ, juste pour une valeur.

En tout cas merci pour avoir tenté de m'aider

[elsuket]

Si la valeur est codée en dur dans la procédure stockée, il faut faire précéder le signe égale par N :

DECLARE @bulgarie nvarchar(64) = N'ОСВОБОДЕНИ от ДДС по Член. 21, Алинея. 2 от ЗДДС'

@++

[trollinou]

Ca c'est THE SOLUTION !!

Merci beaucoup, je m'endormirai moins bête ce soir !