Fonctionnalités internationales dans Microsoft

Fonctionnalités internationales dans Microsoft SQL Server 2005
Formation des utilisateurs SQL Server
Microsoft Corporation
Février 2007
S'applique à :
Microsoft SQL Server 2005
Unicode
Résumé : Ce livre blanc présente aux développeurs Microsoft SQL Server les fonctionnalités
internationales de Microsoft SQL Server 2005. Il propose notamment une explication du
format Unicode et aborde l'ajout de la prise en charge de caractères supplémentaires dans
SQL Server 2005, les modifications du classement dans les différentes versions de
SQL Server, les modifications des types de données, les performances, les mises à jour pour
les fournisseurs de données et les nouvelles fonctionnalités de prise en charge internationales
dans SQL Server 2005 Analysis Services et SQL Server 2005 Integration Services. (75 pages
imprimées)
Sommaire
Introduction
Prise en charge du format Unicode dans SQL Server 2005
Types de données dans SQL Server 2005
Performances et espace de stockage
Migration des informations de métadonnées dans les tables système
Classements
Communications serveur-clients (technologies d'accès aux données)
Données multilingues dans l'interface utilisateur
Transact-SQL en multilingue
Prise en charge des paramètres régionaux dans SQL Server 2005
SQL Server 2005 Integration Services
Utilisation des utilitaires de ligne de commande avec les données multilingues
Fonctionnalités internationales dans SQL Server Analysis Services
Prise en charge du format XML dans SQL Server 2005
Améliorations apportées à la recherche de texte intégral
Interaction avec les autres produits de base de données
Conclusion
Remerciements
Annexe A : Suffixes de classement
Annexe B : Paramètres régionaux pris en charge dans Windows
Annexe C : Ordres de tri spécifiques à SQL
Annexe D : Langues prises en charge dans SQL Server 2005
Annexe E : Langues en texte intégral ajoutées dans SQL Server 2005
Annexe F : Classements mis à jour dans SQL Server 2005
Introduction
Microsoft SQL Server 2005 s'appuie sur la prise en charge d'Unicode et de XML introduite
dans SQL Server 2000 et y ajoute une nouvelle série puissante d'outils de développement et
de requête grâce à SQL Server Management Studio et Business Intelligence Development
Studio. Des fonctionnalités multilingues robustes font de SQL Server 2005 un produit de base
de données et une plate-forme d'applications attrayants pour la prise en charge des opérations
et des environnements au niveau international.
Ce livre blanc offre une vue d'ensemble de ces fonctionnalités dans un contexte global. Il
répertorie les fonctionnalités liées aux exigences des activités internationales et multilingues
et explique comment les décisions de conception peuvent affecter de nombreux aspects d'un
projet.
Remarque : Ce document utilise les polices internationales suivantes pour offrir des
exemples de certains caractères internationaux : Arial Unicode MS, Latha, Mangal,
PmingLiu, Gulim, SimSun et MS-Mincho. Le fait de ne pas avoir ces polices installées
n'affectera pas sérieusement l'applicabilité de ce document.
Unicode Support in SQL Server 2005
La prise en charge des caractères Unicode constitue la base de la prise en charge multilingue
dans SQL Server 2005.
Unicode est une norme créée par le Consortium Unicode, une organisation qui vise à instaurer
un jeu de caractères unique pour toutes les langues. SQL Server 2005 prend en charge la
norme Unicode version 3.2. La version 3.01 de la norme Unicode est identique à ISO-10646,
une norme internationale qui correspond à tous les points de code dans Unicode.
Unicode fournit un point de code unique pour chaque caractère, quels que soient la plateforme, le programme ou la langue. Un programme qui prend en charge Unicode peut gérer
des données dans n'importe quelle langue. Parce qu'il est conçu pour couvrir tous les
caractères de toutes les langues au monde, il n'est pas nécessaire d'utiliser des pages de code
différentes pour gérer différents jeux de caractères.
Dans la mesure où tous les systèmes Unicode utilisent de façon cohérente les mêmes schémas
de bits pour représenter tous les caractères, il existe aucun problème de conversion incorrecte
des caractères en cas de transfert d'un système à un autre.
La façon la plus simple de gérer les données de caractère dans les bases de données
internationales est toujours d'utiliser les types de données Unicode nchar, nvarchar et
nvarchar(max) plutôt que leurs équivalents non Unicode : char, varchar et text. Ainsi, les
clients voient les mêmes caractères dans les données que tous les autres clients. Si toutes les
applications qui utilisent des bases de données internationales exploitent également des
variables Unicode au lieu de variables non Unicode, il n'est pas nécessaire d'exécuter des
conversions de caractères dans le système.
Remarque : Le type de données ntext sera supprimé dans une future version de
Microsoft SQL Server.
Les points de code Unicode et les caractères qu'ils représentent sont séparés du glyphe utilisé
pour le rendu visuel. Un glyphe est défini par la norme ISO (ISO/CEI 9541-1) comme « un
symbole graphique, abstrait et reconnaissable qui est indépendant d'une conception
spécifique ». Donc, un caractère n'est pas nécessairement toujours représenté par le même
glyphe, ou même un glyphe unique. La police que vous choisissez détermine le glyphe qui
sera utilisé pour représenter un point de code ou une série de points de code particuliers.
Pour plus d'informations, consultez le site Web du consortium Unicode.
Codages
Unicode mappe des points de code sur les caractères, mais il ne spécifie pas comment les
données seront représentées dans la mémoire, dans une base de données ou sur une page Web.
C'est là que le codage des données Unicode entre en jeu. Il existe de nombreux de codages
différents pour Unicode. La plupart du temps, vous pouvez simplement choisir un type de
données Unicode sans vous soucier de ces détails. Toutefois, il est important de connaître le
codage lorsque vous êtes dans les situations suivantes :



dans le cas d'une application qui peut coder Unicode différemment ;
lors de l'envoi de données à d'autres plates-formes (autres que Microsoft Windows) ou
des serveurs Web ;
lors de l'importation de données depuis ou l'exportation de données vers d'autres
codages.
La norme Unicode définit plusieurs codages de son jeu de caractères unique : UTF-7, UTF-8,
UTF-16 et UTF-32. Cette section décrit ces codages courants :



UCS-2
UTF-16
UTF-8
Généralement, SQL Server stocke Unicode dans le schéma de codage UCS-2. Cependant, de
nombreux clients traitent Unicode dans un autre schéma de codage, tel qu'UTF-8. Ce scénario
est courant dans les applications Web. Dans les applications Microsoft Visual Basic, les
chaînes de caractères sont traitées dans le schéma de code UCS-2. Vous n'avez donc pas
besoin de spécifier explicitement les conversions de schéma de codage entre les applications
Visual Basic et une instance de SQL Server.
SQL Server 2005 code les données XML en utilisant Unicode (UTF-16). Les données d'une
colonne de type xml sont enregistrées dans un format interne sous forme de gros objets
binaires (BLOB) afin de prendre en charge les caractéristiques du modèle XML, telles que
l'ordre des documents et les structures récurrentes. C'est pourquoi les données XML
récupérées du serveur sortent en UTF-16. Si vous souhaitez un codage différent pour la
récupération de données, votre application doit exécuter la conversion nécessaire sur les
données UTF-16 récupérées. Les pratiques XML recommandées dans les Livres
SQL Server 2005 en ligne fournissent un exemple du mode de déclaration explicite d'un
codage pour les données XML récupérées d'une colonne varchar(max).
Le codage UTF-16 est utilisé parce qu'il peut gérer des caractères de 2 ou 4 octets et est traité
selon un protocole orienté octets. Ces qualités font d'UTF-16 un schéma de codage
particulièrement bien adapté pour traverser différents ordinateurs utilisant des codages et des
systèmes d'ordonnancement d'octet différents. Dans la mesure où les données XML sont
généralement largement partagées sur les réseaux, il est judicieux de maintenir le stockage
UTF-16 par défaut des données XML dans votre base de données et lorsque vous exportez les
données XML vers les clients.
UCS-2
UCS-2 est un prédécesseur d'UTF-16. UCS-2 diffère d’UTF-16 dans le sens où UCS-2 est un
codage de longueur fixe qui représente tous les caractères sous forme de valeur 16 bits
(2 octets) et ne prend donc pas en charge de caractères supplémentaires. UCS-2 est
fréquemment confondu avec UTF-16, qui est utilisé en interne pour représenter le texte dans
les systèmes d'exploitation Microsoft Windows (Windows NT, Windows 2000, Windows XP
et Windows CE), mais UCS-2 est plus limité.
Remarque : Pour obtenir les toutes dernières informations sur l'utilisation d'Unicode dans le
système d'exploitation Windows, consultez la rubrique Unicode dans la bibliothèque MSDN
(Microsoft Developer Network). Il est recommandé qu'une application Windows utilise UTF16 en interne et ne soit converti dans le cadre d'une « thin layer » via l'interface que si un autre
format doit être utilisé.
Les informations enregistrées en Unicode dans Microsoft SQL Server 2000 et
Microsoft SQL Server 2005 utilisent le codage UCS-2, qui enregistre chaque caractère sous la
forme de deux octets, quel que soit le caractère utilisé. Ainsi, la lettre latine « A » est traitée
de la même façon que le caractère cyrillique Sha ()), le caractère hébraïque Lamed (ì), le
caractère tamoul Rra (?) ou le caractère japonais Hiragana E (‚¦). Chacun possède un point de
code unique (pour ces lettres, les points de code sont U+0041, U+0248, U+05DC, U+0BB1 et
U+3048 respectivement, où chaque nombre hexadécimal à quatre chiffres représente les deux
octets utilisés par UCS-2).
Dans la mesure où UCS-2 n'autorise que 65 536 points de code différents pour le codage, il ne
gère pas en natif les caractères supplémentaires. Il traite plutôt les caractères supplémentaires
comme une paire de caractères Unicode de substitution non définis qui, lorsqu'ils sont
appariés, définissent un caractère supplémentaire. Cependant, SQL Server peut enregistrer des
caractères supplémentaires sans risque de perte ou d'altération. Vous pouvez étendre les
fonctionnalités de SQL Server pour utiliser les paires de substitution en créant des fonctions
CLR personnalisées. Pour plus d'informations sur l'utilisation des paires de substitution et des
caractères supplémentaires, reportez-vous à la section « Caractères supplémentaires et paires
de substitution », plus loin dans ce livre blanc.
Remarque : Les caractères supplémentaires se définissent comme étant « un caractère codé
en Unicode possédant un point de code supplémentaire ». Les points de code supplémentaires
se trouvent dans la plage entre U+10000 et U+10FFFF.
UTF-8
UTF-8 est un schéma de codage conçu pour traiter les données Unicode indépendamment de
l'ordonnancement des octets sur l'ordinateur. UTF-8 est utile pour travailler avec ASCII et
d'autres systèmes orientés sur les octets qui nécessitent des codages de 8 bits, tels que les
serveurs de messagerie qui doivent couvrir un vaste groupe d'ordinateurs utilisant des codages
différents, des ordres d'octet différents et des langues différentes. Bien que SQL Server 2005
n'enregistre pas de données au format UTF-8, il prend en charge UTF-8 pour traiter les
données XML (Extensible Markup Language). Pour plus d'informations, consultez la section
Prise en charge du format XML dans SQL Server 2005 de ce document.
D'autres systèmes de base de données, tels qu'Oracle et Sybase SQL Server, prennent en
charge Unicode en utilisant le stockage UTF-8. En fonction de l'implémentation d'un serveur,
cela peut être techniquement plus facile à mettre en œuvre pour un moteur de base de
données, parce que le code de gestion de texte existant sur le serveur ne nécessite pas de
modifications majeures pour traiter les données octet par octet. Cependant, dans
l'environnement Windows, le stockage UTF-8 présente plusieurs inconvénients :




Le modèle COM (Component Object Model) prend uniquement en charge UTF16/UCS-2 dans ses API et interfaces. Donc, si des données sont enregistrées au format
UTF-8, une conversion constante est nécessaire. Ce problème n'apparaît qu'avec
l'utilisation de COM. Le moteur de base de données SQL Server n'appelle
généralement pas les interfaces COM.
Les noyaux de Windows XP et Windows Server 2003 sont tous les deux en Unicode.
UTF-16 est le codage standard pour Windows 2000, Windows XP et Windows
Server 2003. Ils sont toutefois compatibles avec UTF-8. C'est pourquoi l'utilisation
d'un format de stockage UTF-8 dans la base de données nécessite de nombreuses
conversions supplémentaires. De façon générale, les ressources supplémentaires
nécessaires pour la conversion n'affectent pas le moteur de base de données
SQL Server, mais elles peuvent potentiellement affecter de nombreuses opérations
côté client.
UTF-8 peut être plus lent pour un grand nombre d'opérations de chaîne. Le tri, la
comparaison et presque n'importe quelle opération de chaîne peuvent être ralentis car
les caractères n'ont pas de largeur fixe.
UTF-8 a souvent besoin de plus de 2 octets et l'augmentation de la taille peut produire
un plus grand encombrement sur le disque et dans la mémoire.
Malgré ces inconvénients, étant donné que XML est devenu une norme importante pour la
communication sur Internet, vous souhaiterez peut-être envisager d'utiliser UTF-8 par défaut.
Remarque : Les anciennes versions d'Oracle et Java utilisent également UCS-2 et ne
peuvent pas reconnaître les paires de substitution. Oracle Corporation a commencé à prendre
en charge Unicode comme jeu de caractères de base de données dans Oracle 7. Oracle prend
actuellement en charge deux méthodes de stockage des données Unicode : (1) UTF-8 comme
schéma de codage des types de données de caractères CHAR et VARCHAR2, et pour tous les
noms et littéraux de SQL ; (2) UTF-16 pour le stockage des types de données Unicode
NCHAR, NVARCHAR et NCLOB. Oracle vous permet d'utiliser les deux méthodes en même
temps.
UTF-16
UTF-16 est le schéma de codage utilisé chez Microsoft et dans le système d'exploitation
Windows. UTF-16 est une extension destinée à gérer 1 048 576 caractères supplémentaires.
La nécessité d'une plage de substitution a été reconnue avant même l'apparition d'Unicode 2.0,
car il était devenu évident que l'objectif d'Unicode d'utiliser un seul point de code pour chaque
caractère de chaque langue ne pourrait pas être atteint en utilisant seulement
65 536 caractères. Par exemple, certaines langues comme le chinois nécessitent au moins ce
nombre de caractères pour coder des caractères tels que les idéogrammes historiques et
littéraires, qui, bien que rarement utilisés, sont néanmoins importants pour l'édition et les
sciences universitaires. La section suivant fournit de plus amples informations sur la plage de
substitution.
Tout comme UCS-2, UTF-16 utilise un ordre d'octets Little Endian, comme tout ce qui touche
Windows. Little Endian, à la différence de Big Endian, implique que l'octet d'ordre faible est
enregistré à l'adresse la plus basse dans la mémoire. L'ordonnancement des octets est
important au niveau du système d'exploitation. SQL Server, ainsi que d'autres applications
s'exécutant sur la plate-forme Windows, utilise l'ordre d'octets Little Endian. C'est pourquoi
un mot hexadécimal tel que 0x1234 est enregistré dans la mémoire sous la forme 0x34 0x12.
Dans certains cas, vous pourrez avoir besoin d'inverser explicitement l'ordre des octets pour
lire correctement le codage d'un caractère. SQL Server Integration Services fournit des
fonctions permettant de convertir l'ordre des octets d'un texte Unicode. Pour plus
d'informations, consultez la section SQL Server 2005 Integration Services de ce document.
Caractères supplémentaires et paires de substitution
Microsoft Windows utilise normalement UTF-16 pour représenter les données de caractère.
L'utilisation de 16 bits permet de représenter 65 536 caractères uniques. Cependant, cela ne
suffit pas pour couvrir tous les symboles utilisés dans les langues humaines. Dans UTF-16,
certains points de code utilisent un autre point de code immédiatement après les deux
premiers octets pour définir le caractère comme appartenant à la plage de substitution.
La norme Unicode compte 16 plans de caractères, avec la possibilité de définir 1 114 112
caractères. Le plan 0, ou BMP (Basic Multilingual Plane), peut représenter la plupart des
scripts écrits dans le monde, les caractères utilisés dans l'édition, les symboles mathématiques
et techniques, les formes géométriques, toutes les vignettes de niveau 100 Zapf et les signes
de ponctuation.
En dehors de BMP, les caractères de la plupart des plans ne sont pas encore définis, mais ils
peuvent être utilisés pour représenter des caractères supplémentaires. Les caractères
supplémentaires sont principalement utilisés pour les documents historiques et littéraires
classiques afin de faciliter le codage du riche héritage littéraire du chinois, du coréen et du
japonais. Les caractères supplémentaires incluent également des runes et d'autres scripts
historiques, les symboles musicaux, etc.
Dans UTF-16, une paire de points de code, appelée paire de substitution, est utilisée pour
représenter des caractères hors du jeu de caractères principal (BMP). Le secteur de
substitution est une plage Unicode entre U+D800 et U+DFFF qui contient 1 024 valeurs de
substitution faible et 1 024 valeurs de substitution étendue. Un substitut étendu (la plage
U+D800 à U+DBFF) et un substitut faible (la plage U+DC00 à U+DFFF) sont combinés pour
donner accès à plus d'un million de caractères possibles.
Il n'est pas considéré valide d'avoir seulement une moitié d'une paire de substitution ; pour
qu'un caractère soit valide, il doit toujours y avoir un substitut étendu suivi d'un substitut
faible. Par conséquent, la vérification d'un substitut devient une question de vérification de
plage, qui est facile en comparaison des règles plutôt complexes qui sont nécessaires pour
détecter les caractères DBCS (double-byte character system – système de caractère à deux
octets).
SQL Server 2000 et SQL Server 2005 peuvent tous deux enregistrer des paires de
substitution, bien qu'UCS-2 ne reconnaisse pas les substituts. SQL Server traite les paires de
substitution comme deux caractères Unicode non définis et non un seul caractère. Ce type
d'applications est généralement appelé de substitution neutre ou de substitution sûre, ce qui
signifie qu'il n'existe pas de possibilité intrinsèque d'interagir avec les données, mais qu'au
moins les données peuvent être enregistrées sans risque de perte.
Par opposition, les applications compatibles avec les caractères de substitution peuvent non
seulement prendre en compte les paires de substitution, mais également traiter les
combinaisons de caractères et les autres caractères nécessitant un traitement spécial. Une
application bien écrite peut détecter des substituts séparés, et les recombiner, en utilisant
seulement quelques sous-routines. Les applications compatibles avec les caractères de
substitution sont notamment Microsoft Word et Internet Explorer 5 et versions ultérieures.
Quand vous travaillez avec des caractères supplémentaires dans SQL Server, rappelez-vous
les points suivants :




Dans la mesure où les paires de substitution sont considérées comme deux points de
code Unicode séparés, la taille des caractères nvarchar(n) doit être 2 pour contenir un
seul caractère supplémentaire (en d'autres termes, un espace pour une paire de
substitution).
L'utilisation des caractères supplémentaires n'est pas prise en charge dans les
métadonnées, par exemple dans les noms des objets de base de données. En général, le
texte utilisé dans les métadonnées doit répondre aux règles fixées pour les
identificateurs. Pour plus d'informations, consultez la section Identificateurs dans la
documentation en ligne de SQL Server 2005.
Les opérations de chaîne standard ne reconnaissent pas les caractères supplémentaires.
Les opérations telles que SUBSTRING(nvarchar(2),1,1) ne renvoient que le substitut
étendu de la paire de substitution du caractère supplémentaire. La fonction LEN
renvoie le décompte de deux caractères pour chaque caractère supplémentaire
rencontré : un pour le substitut étendu et un pour le substitut faible. Cependant, vous
pouvez créer des fonctions personnalisées qui détectent les caractères supplémentaires.
L'échantillon StringManipulate dans la section Manipulation de chaînes compatibles
avec les caractères supplémentaires de la documentation en ligne de SQL Server 2005,
explique comment créer de telles fonctions.
Le comportement des fonctions de tri et de recherche des caractères supplémentaires
peut varier en fonction du classement. Dans les nouveaux classements _90 et BIN2,
les caractères supplémentaires sont correctement comparés, tandis que dans les
classements plus anciens et les classements standard de Windows, tous les caractères
supplémentaires sont considérés égaux à tous les autres caractères supplémentaires.
Par exemple, les classements japonais et coréens par défaut ne gèrent pas de caractères
supplémentaires, contrairement à Japanese_90 et Korean_90.
Pour plus d'informations sur les points de code Unicode, les pratiques recommandées pour
concevoir des applications reconnaissant les substitutions et l'utilisation des données Unicode,
consultez l'article Globalisation étape par étape : compatibilité Unicode). Pour plus
d'informations sur les plages de caractères prises en charge dans la norme Unicode, consultez
la section relative aux expressions Unicode régulières dans Norme standard Unicode n°18.
Caractères combinés
Les caractères combinés sont des caractères utilisés conjointement à d'autres caractères pour
modifier leur apparence ou leur signification. Les caractères combinés forment un seul
glyphe. Par exemple, les signes diacritiques utilisés dans les langues européennes sont des
caractères combinés qui peuvent soit apparaître sous forme de caractère plus diacritique, soit
sous forme de caractère précomposé.
Dans .NET Framework, la séquence de caractères combinés est traitée comme un élément de
texte (en d'autres termes, une unité de texte affichée comme un seul caractère). Un élément de
texte est différent d'un élément de tri. Par exemple, dans certains classements, les lettres
« CH » ne sont pas des caractères combinés ; ils sont deux éléments de texte séparés, mais
peuvent être traités comme un élément de tri.
Remarque : Les fonctions SQL, d'un autre côté, traitent généralement les caractères
combinés de la même façon que les caractères supplémentaires : elles les traitent comme deux
points de code Unicode séparés. Pour obtenir un exemple de création d'une fonction
personnalisée qui compte et compare plus précisément les caractères supplémentaires,
consultez l'échantillon StringManipulate.
La façon dont les caractères combinés se mappent sur des éléments de tri dépend de la norme
Unicode et du classement. Certains caractères combinés sont toujours considérés comme
l'équivalent de leurs formes variables, sans tenir compte du nombre de points de code
différents qu'ils incluent (par exemple, la lettre latine a plus un diacritique est traitée comme
l'équivalent de la lettre précomposée, y compris le signe diacritique), tandis que dans certains
classements il est possible de trier ou de comparer des chaînes différemment, en fonction de la
présence du signe diacritique.
Les caractères combinés ont été définis pour la première fois dans Unicode 2.0. Pour plus
d'informations, consultez la section des spécifications Unicode 4.0.1 qui traite des Zones
spéciales et des Caractères de format. Le Consortium Unicode publie également un forum aux
questions spécifique pour les caractères combinés et leur traitement. Pour plus d'informations
sur les méthodes de traitement des caractères combinés dans .NET Framework, consultez la
section Normalisation dans le guide du développeur de .NET Framework.
Prise en charge pour GB18030
GB18030 (GB18030-2000) est une norme distincte rendue obligatoire par la République
populaire de Chine (PRC) pour coder les caractères chinois. Elle spécifie une page de code et
une table de mappage étendues à Unicode. Depuis le 1er août 2006, la prise en charge de ce
jeu de caractères est officiellement exigée pour tous les produits logiciels vendus en PRC. La
conformité à GB18030 inclut des exigences de prise en charge de certaines langues qui ne
l'étaient pas précédemment (par exemple, le tibétain, le mongol, le yi et l'ouïgour.
Dans GB18030, les caractères peuvent être de 1, 2 ou 4 octets. Des paires de substitution sont
utilisées pour permettre le mappage de séquences GB18030 de 4 octets sur Unicode.
SQL Server 2005 fournit la prise en charge de caractères codés en GB18030 dans la mesure
où il les reconnaît lorsqu'ils entrent dans le serveur à partir d'une application côté client.
SQL Server 2005 convertit et enregistre ces caractères en natif au format Unicode. Ensuite, ils
sont enregistrés dans le serveur et traités en tant que caractères Unicode dans les opérations
suivantes exécutées sur eux. GB18030 ne possède pas de paramètre régional; il a seulement
un identificateur de page de code afin d'autoriser les conversions vers et depuis Unicode.
L'identificateur de page de code Microsoft pour GB18030-2000 est 54936.
Lorsque vous utilisez des caractères GB18030, n'oubliez pas qu'ils peuvent être utilisés dans
les opérations de tri et de comparaison, mais dans les classements antérieurs à SQL Server 90,
les comparaisons sont seulement basées sur leurs points de code et pas sur d'autres méthodes
qui seraient plus logiques sur le plan linguistique. Faites par conséquent attention lorsque
vous utilisez des caractères GB18030 dans des opérations telles que ORDER BY, GROUP
BY et DISTINCT, surtout lorsque des caractères GB18030 et non GB18030 sont inclus dans
une même opération. Pour autoriser les comparaisons de chaînes significatives qui utilisent
des caractères GB18030, utilisez la nouvelle version du classement SQL Server 90, indiquée
par le suffixe 90 ajouté à son nom. Par exemple, au lieu du classement Chinese_PRC, utilisez
Chinese_PRC_90.
Pour activer la prise en charge de la norme GB18030, vous pouvez installer un package de
prise en charge, disponible sur le portail Aide et support Microsoft, qui inclut un fichier de
polices et des bibliothèques pour prendre en charge la conversion entre GB18030 et Unicode.
Le package de prise en charge est un binaire international unique qui fonctionne sous
Windows XP ou Windows 2000. Cependant, la prise en charge facultative des langues
d'Extrême-Orient doit être installée sur le système. Dans Windows Vista, la prise en charge de
la norme GB18030 est incluse, y compris les polices et les configurations clavier pour les
langues minoritaires de Chine tels que le tibétain, le mongol, le yi et l'ouïgour. Ces langues
utilisent les paramètres régionaux chinois (RPC).
Remarque : Certaines fonctions permettant de convertir les octets GB18030 en caractères
Unicode, telles que BytesToUnicode, ne sont pas prises en charge dans Vista. Lors de la
conversion d'octets GB18030 en caractères Unicode dans Vista, utilisez la fonction
MultiByteToWideChar.
Pour plus d'informations sur la prise en charge de cette norme dans les produits Microsoft,
consultez le portail Microsoft Global Development and Computing sur Microsoft.com.
Types de données dans SQL Server 2005
Cette section décrit les nouveaux types de données dans SQL Server 2005 et explique les
problèmes relatifs à l'utilisation de types de données SQL Server 2005 pour enregistrer les
données internationales.
Types de texte non Unicode : char, varchar, text, varchar(max)
Lorsque vous traitez des données de texte enregistrées dans le type de données char, varchar,
varchar(max) ou text, la principale restriction à prendre en compte est que seules les
informations d'une page de code unique peuvent être validées par le système. (Vous pouvez
enregistrer des données à partir de plusieurs pages de code, mais ce n'est pas recommandé).
La page de code exacte utilisée pour valider et enregistrer les données dépend du classement
de la colonne. Si un classement au niveau colonne n'a pas été défini, le classement de la base
de données est utilisé. Pour déterminer la page de code utilisée pour une colonne donnée, vous
pouvez utiliser la fonction COLLATIONPROPERTY, comme illustré dans les exemples de
code suivants :
SELECT COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI_KS_WS', 'CodePage')
936
SELECT COLLATIONPROPERTY('Latin1_General_CI_AI', 'CodePage')
1252
SELECT COLLATIONPROPERTY('Hindi_CI_AI_WS', 'CodePage')
0
Le dernier exemple renvoie 0 (Unicode) comme page de code pour l'hindi. Cet exemple
illustre le fait que de nombreux paramètres régionaux, tels que le géorgien et l'hindi, ne
possèdent pas de pages de code, car il s'agit de classements Unicode uniquement. Ces
classements ne conviennent pas pour les colonnes qui utilisent le type de données char,
varchar ou text, et certains classements ont été désapprouvés. Pour une liste des classements
disponibles et des classements Unicode uniquement, consultez la section Paramètres de
classement dans la configuration dans la documentation en ligne de SQL Server 2005.
Important Dans SQL Server 2005, utilisez le type de données varchar(max) plutôt que le
type de données text. Remarque : Le type de données text sera supprimé dans une future
version de Microsoft SQL Server. Pour plus d'informations, consultez la section Utilisation
des types de données de valeur étendue dans la documentation en ligne de SQL Server 2005.
Lorsque des données Unicode doivent être insérées dans des colonnes non Unicode, les
colonnes sont converties en interne à partir d'Unicode en utilisant l'API
WideCharToMultiByte et la page de code associée au classement. Si un caractère ne peut
pas être représenté sur la page de code donnée, il est remplacé par un point d'interrogation (?).
Par conséquent, l'apparition de points d'interrogation aléatoires dans vos données constitue
une indication fiable de la corruption de vos données en raison d'une conversion non
spécifiée. Elle est également une bonne indication que votre application pourrait bénéficier de
la conversion à un type de données Unicode.
Si vous utilisez un littéral de chaîne d'un type non Unicode qui n'est pas pris en charge par le
classement, la chaîne est convertie d'abord en utilisant la page de code de la base de données
par défaut, elle-même dérivée du classement par défaut de la base de données.
Un autre problème que vous pourriez rencontrer réside dans l'impossibilité d'enregistrer des
données lorsque tous les caractères que vous souhaitez prendre en charge ne sont pas contenus
dans la page de code. Dans de nombreux cas, Windows considère une page de code
particulière comme la page de code « la mieux adaptée », ce qui signifie qu'il n'est pas garanti
que vous puissiez vous baser sur la page de code pour traiter tout le texte : il s'agit simplement
de la meilleure disponible. Le script arabe est un exemple de ce cas de figure : il prend en
charge une grande variété de langues, y compris le baloutchi, le berbère, le persan, le
kashmiri, le kazakh, le kirghiz, le kurde, le pachto, le sindhi, l'ouïgour, l'urdu, et bien d'autres
encore. Toutes ces langues ont des caractères supplémentaires par rapport à la langue arabe,
comme définie dans la page de code Windows 1256. Si vous tentez d'enregistrer ces
caractères supplémentaires dans une colonne non Unicode utilisant le classement arabe, les
caractères sont transformés en points d'interrogation.
Types de texte Unicode : nchar, nvarchar, nvarchar(max), ntext
La spécification SQL-92 définit les types de données précédés par « N » (soit les types de
données « nationaux »), mais ne nécessite pas spécifiquement que les types de données soient
utilisés pour Unicode. La véritable définition de ces types de données dépend de la plateforme de base de données ou du développeur. Dans SQL Server 2000 et SQL Server 2005,
ces types de données sont définis comme équivalents à UCS-2, qui est un codage Unicode.
Cependant, lorsque vous travaillez avec d'autres serveurs de base de données, il est important
de savoir que les types de données « N » ne signifient pas spécifiquement Unicode. La
décision de définir les types de données « N » comme Unicode est spécifique à
Microsoft SQL Server.
Le type de données nvarchar(max), nouveau dans SQL Server 2005, contient jusqu'à
2 gigaoctets (Go) de données et constitue l'alternative de prédilection au type de données
ntext.
Important Dans SQL Server 2005, utilisez le type de données nvarchar(max) plutôt que le
type de données ntext. Remarque : Le type de données text sera supprimé dans une future
version de Microsoft SQL Server. Pour plus d'informations, consultez la section Utilisation
des types de données de valeur étendue dans la documentation en ligne de SQL Server 2005.
Pour le stockage de scripts complexes, tels que l'hindi et le tamoul, assurez-vous que les
données sont dans le bon ordre. Beaucoup de langues, tels que le tamoul, spécifient que
certaines lettres sont retriées lors de l'affichage du texte. Par conséquent, l'ordre logique du
texte tel qu'il est enregistré en mémoire peut être différent de l'ordre visuel qui sera perçu dans
une interface utilisateur. Les données doivent toujours être enregistrées dans le bon ordre
logique pour tout langage de script complexe, c'est-à-dire toutes les langues indiennes, l'arabe,
le persan, l'hébreu et bien d'autres. Le rendu effectif de telles données est un problème à part
(voir la section les Données multilingues dans l'interface utilisateur de ce document).
Bien que les colonnes « N » puissent prendre en charge les données de n'importe quelle
langue ou n'importe quelle combinaison de langues, lorsque vous triez les données, vous ne
pouvez choisir qu'un seul classement. Pour en apprendre plus sur la façon de choisir un
classement, consultez la section Classements de ce livre blanc. Aucune des restrictions de
page de code précédemment mentionnées ici ne s'applique aux colonnes Unicode.
Dans SQL Server 2005, vous pouvez créer des fonctions complémentaires pour améliorer la
manipulation des chaînes et le comportement du classement avec les caractères
supplémentaires. Par exemple, l'échantillon StringManipulate pour
Microsoft SQL Server 2005 présente le traitement de chaînes avec reconnaissances des
caractères supplémentaires. Cet échantillon indique comment implémenter cinq fonctions de
chaîne Transact-SQL qui fournissent les mêmes fonctions de manipulation de chaîne que les
fonctions de chaîne prédéfinies, mais avec en plus la capacité de reconnaissance des
caractères supplémentaires afin de gérer les chaînes de caractères Unicode et supplémentaires.
Types de données CLR
Microsoft SQL Server vous offre la possibilité d'étendre le système de type de SQL en
définissant un type de données personnalisé pouvant être utilisé dans la programmation
SQL Server. Ces types définis par l'utilisateur sont bien adaptés pour la création personnalisée
des types de date, d'heure, de devise et numériques étendus, ou pour les données codées ou
chiffrées.
Un type défini par l'utilisateur peut être utilisé pour définir le type d'une colonne dans une
table, ou un paramètre de variable ou routine dans le langage Transact-SQL. Une instance
d'un type défini par l'utilisateur peut être une colonne dans une table, une variable dans une
commande, une fonction ou une procédure stockée, ou un argument d'une fonction ou d'une
procédure stockée. Un type défini par l'utilisateur est implémenté comme une classe gérée
dans n'importe quel langage CLR, puis enregistré avec SQL Server. Pour plus d'informations
sur la manière de mettre en œuvre un type défini par l'utilisateur en utilisant Visual Basic ou
Microsoft Visual C#, consultez la section Codage des types définis par l'utilisateur dans la
documentation en ligne de SQL Server 2005.
Vous pouvez utiliser des types définis par l'utilisateur pour étendre le système de type scalaire
du serveur, ce qui permet le stockage d'objets CLR dans une base de données SQL Server.
Les types définis par l'utilisateur peuvent contenir plusieurs éléments et suivre des
comportements spéciaux définis par l'utilisateur. Ceci les différencie du type de données alias
traditionnel, qui consiste en un type de données système SQL Server unique. Par exemple,
l'exemple de type défini par l'utilisateur Currency fourni dans la documentation en ligne de
SQL Server 2005 prend en charge la gestion de sommes d'argent dans le système monétaire
d'une culture particulière. Vous devez définir deux champs : Une valeur string pour
CultureInfo, qui spécifie la source de la devise (par exemple, fr-fr) et une valeur decimal pour
CurrencyValue, pour représenter la quantité d'argent.
Dans la mesure où le système dans son ensemble accède aux types définis par l'utilisateur,
leur utilisation pour les types de données complexes peut diminuer les performances. Les
données complexes sont généralement mieux modélisées en utilisant des lignes et des tables
traditionnelles. La documentation en ligne de SQL Server 2005 inclut plusieurs exemples qui
expliquent comment créer et exploiter les types personnalisés définis par l'utilisateur.
L'exemple UTF8String pour SQL Server 2005 démontre comment implémenter un type de
données défini par l'utilisateur qui étend le système de types de la base de données afin de
fournir le stockage des valeurs codées par UTF8. Ce nouveau type implémente également le
code permettant de convertir les chaînes Unicode vers et depuis UTF8. Pour plus
d'informations, consultez la section Type de données défini par l'utilisateur (UDT) d'une
chaîne UTF8 dans la documentation en ligne de SQL Server 2005.
Pour des exemples supplémentaires, consultez la section Exemples de programmation CLR
dans la documentation en ligne de SQL Server 2005.
Type de données XML
Le type de données XML vous permet d'enregistrer un fragment ou un document XML dans
des bases de données SQL Server. Les instances du type de données XML peuvent être des
colonnes dans une table, des fonctions ou des arguments de procédure stockée, ou des
variables dans une fonction ou une procédure stockée. De plus, le type de données XML peut
être spécialisé en indiquant un schéma XML associé qui fournit les contraintes de validation
et les informations de type de données pour l'instance XML.
Vous exécutez des opérations sur une instance d'un type de données XML en utilisant les
méthodes d'interrogation XML incorporées. Ces méthodes acceptent les requêtes et les relevés
de manipulation de données qui sont appropriés pour les données XML. Vous pouvez ensuite
spécifier des requêtes (XQuery) sur le document XML enregistré dans la variable de type de
données ou la colonne XML, puis appliquer des mises à jour (en utilisant les commandes
insert, update ou delete) à l'instance XML. Vous pouvez également utiliser un XSD pour créer
un index pour la colonne XML, ce qui améliorera les performances des requêtes.
Pour plus d'informations sur le type de données xml et les fonctionnalités de
SQL Server 2005 visant à prendre en charge le traitement de données XML, consultez la
section Prise en charge du format XML dans SQL Server 2005 de ce document.
Types date/heure : datetime, smalldatetime
Les types de données de date et d'heure utilisés dans SQL Server 2000 et SQL Server 2005
ont les définitions suivantes :
datetime
Les données de date et d'heure du calendrier grégorien du s'étendant du 1 janvier 1753 au
31 décembre 9999, avec une précision d'un trois centième de seconde (soit 3,33 millisecondes
ou 0,00333 secondes).
smalldatetime
Données de date et d'heure du calendrier grégorien s'étendant du 1 janvier 1900 au
6 juin 2079, avec une précision à la minute. Les valeurs smalldatetime avec 29,998 secondes
ou moins sont arrondies à la minute inférieure la plus proche ; les valeurs avec
29,999 secondes ou plus sont arrondies à la minute supérieure la plus proche.
Microsoft SQL Server rejette les données en dehors de ces plages. Les données réelles sont
enregistrées en interne sous forme de deux nombres entiers qui représentent la date et l'heure
en question (entiers de 4 octets pour datetime et entiers de 2 octets pour smalldatetime).
Les données stockées ne représentent pas une heure locale ou une heure universelle et ne
contiennent pas d'informations sur le fuseau horaire. Si vous avez besoin de convertir des
dates à l'heure universelle, vous pouvez utiliser l'une des fonctions de date UTC. L'heure UTC
actuelle est dérivée de l'heure locale actuelle et du paramètre de fuseau horaire dans le
système d'exploitation de l'ordinateur sur lequel s'exécute l'instance de Microsoft SQL Server.
La valeur ne possédant pas de format intrinsèque spécifique au lieu, il appartient au
développeur de définir les conversions nécessaires. SQL Server prend en charge de
nombreuses conversions spécifiques aux paramètres régionaux, qui peuvent être exécutées au
niveau serveur, au lieu de se baser sur les solutions personnalisées des développeurs. Ces
styles de date sont accessibles via la fonction CONVERT, qui utilise un type de données, une
expression et un style facultatif, comme illustré dans le tableau suivant.
Avec siècle
Sans siècle
Standard
0 ou 100
101
102
1
2
Par défaut
Anglais (États-Unis)
ANSI
Entrée (conversion en datetime)
Sortie (conversion en text)
mois jj aaa hh: miAM (ou PM)
mm/jj/aa
aa.mm.jj
103
3
104
105
106
107
108
9 ou 109
4
5
6
7
8
-
110
111
112
13 ou 113
10
11
12
-
114
20 ou 120
21 ou 121
14
-
126
-
130
131
-
Anglais (Royaumejj/mm/aa
Uni)/Français
Allemand
jj.mm.aa
Italien
jj-mm-aa
jj mois aa
Mois jj, aa
hh:mm:ss
Par défaut +
mois jj aaaa hh:mi:ss:mmmAM
millisecondes
(ou PM)
Anglais (États-Unis) mm-jj-aa
Japon
aa/mm/jj
ISO
aammjj
Par défaut en Europe + jj mois aaaa hh:mm:ss:mmm(24h)
millisecondes
hh:mi:ss:mmm(24h)
ODBC canonique
aaaa-mm-jj hh:mi:ss(24h)
ODBC canonique +
aaaa-mm-jj hh:mi:ss.mmm(24h)
millisecondes
ISO8601 (aucun
aaaa-mm-jj Thh:mm:ss:mmm
espace)
koweïtien (Hijri)
jj mois aaaa hh:mi:ss:mmmAM
koweïtien (Hijri)
jj/mm/aa hh:mi:ss:mmmAM
L'exemple suivant montre comment la fonction CONVERT est utilisée pour représenter la
date actuelle dans un style spécifié :
SELECT CONVERT(char, GETDATE(), 100) AS [100]
RETURNS:
Aug 16 2000 11:50AM
Vous pouvez ensuite convertir les données d'une chaîne en une valeur de date de façon très
semblable :
SELECT CONVERT(datetime, 'Aug 16 2000 11:50AM', 100) AS [100]
RETURNS:
100
2000-08-16 11:50:00.000
Si vous convertissez des dates dans le style 130 (koweïtien ou hijri) vers un type de données
char, les données peuvent être altérées si le classement n'est pas l'un des classements arabes
utilisant la page de code 1256 pour les conversions Unicode. Par exemple, la figure 1 illustre
une colonne convertie en char et une deuxième colonne convertie en nchar. Dans cet
exemple, l'ordinateur client utilise le paramètre régional EN-US. Par conséquent, lorsque vous
tentez d'utiliser le type de données char, les caractères arabes sont transformés en point
d'interrogation, tandis que si vous utilisez le type de données nchar, les caractères arabes
apparaissent.
Figure 1.Utilisation de la fonction CONVERT avec les données de date/heure (Cliquez
sur l'image pour l'agrandir)
Cependant, même la chaîne représentée avec nchar n'a toujours pas le format correct, comme
ce serait le cas sur un ordinateur client arabe, à cause des restrictions dans l'Éditeur de
requête. La figure 2 illustre la présentation de la chaîne de date correcte du calendrier hijri.
Figure 2. Chaîne de date hijri
L'arabe ne peut pas être affiché correctement parce que les scripts complexes, tels que l'arabe,
ont des règles de mise en page qui contrôlent le rendu des données. Dans le cas des langues
bidirectionnelles (BIDI) telles que l’hébreu, la mise en page entraîne l'inversion de toutes les
données. Dans le cas de l'arabe, la mise en page a un effet plus marqué, parce que les formes
réelles des lettres peuvent changer en fonction des lettres environnantes. Ce problème ne
survient pas dans les versions de Windows postérieures à Windows 2000, ou dans les versions
arabes précédentes de Windows.
De plus, la chaîne de date qui est renvoyée peut causer des problèmes dans les situations
bidirectionnelles où elle est nécessaire, parce que les règles de mise en page du texte
bidirectionnel utilisé par une application (telle qu'Internet Explorer) provoquent l'affichage de
la date comme illustré à la figure 3.
Figure 3. Exemple de chaîne de date bidirectionnelle
Cet ordre visuel (jj hh:mi:ss aaaa mois :) n'est évidemment pas l'ordre prévu ; il est possible
de considérer le problème comme étant une restriction générale du style 130 dans la fonction
CONVERT. Vous pouvez contourner ce problème en ajoutant le caractère de contrôle
Unicode correct devant la chaîne, comme dans la requête suivante :
SELECT NCHAR(8207) + CONVERT(nchar, GETDATE(), 130)
La fonction NCHAR retourne un caractère basé sur le point de code Unicode transmis. 8207
ou 0x200F en hexadécimal est le marqueur Droite à gauche (RLM, Right-to-Left Marker) et il
permet l'affichage correct de la chaîne.
Performances et espace de stockage
Si vous définissez une colonne en utilisant l'un des types de données Unicode, vous pouvez
rencontrer les problèmes suivants, liés à l'espace de stockage et à la vitesse.
Augmentation de l'espace de stockage
Les types de données Unicode utilisent deux octets ou plus par caractère, tandis que les types
de données non Unicode utilisent un octet pour tout texte non DBCS et deux octets pour les
langues asiatiques utilisant DBCS. Par conséquent, à moins que vos données n'utilisent l'une
des pages de code asiatiques, lors d'une conversion en Unicode vous utiliserez deux fois plus
d'espace pour enregistrer les données. L'augmentation de l'espace de stockage nécessaire doit
être prise en compte lorsque vous mettez à niveau des bases de données existantes, ou lorsque
vous devez choisir les types de données corrects pour un nouveau projet. Si vous enregistrez
uniquement des données dans une colonne qui est sur une seule page de code (non asiatique),
vous préférerez peut-être ne pas utiliser Unicode afin d'économiser de l'espace sur le disque et
dans la mémoire. Cependant, les avantages de la conversion Unicode compensent
généralement l'impact sur le stockage.
Remarque : Lors de l'enregistrement de données DBCS asiatiques, la méthode de codage
UCS-2 utilisée par SQL Server 2005 tend à être plus efficace que la méthode UTF-8 utilisée
par beaucoup d'autres programmes de base de données. C'est parce que UTF-8 utilise trois
octets pour stocker la plupart des caractères de langues asiatiques, alors que UCS-2 n'en
utilise que deux (à l'exception des caractères supplémentaires et des caractères combinés).
D'autre part, pour les langues non DBCS, comme les caractères de base ASCII, UTF-8 utilise
généralement seulement un octet par caractère, alors que UCS-2 en utilise deux.
Problèmes de vitesse
L'impact de l'utilisation de types de données Unicode sur les performances est complexe.
Vous devez prendre en compte les problèmes suivants :






Si vous utilisez Windows XP, Windows Server 2003 ou Windows Vista, le système
d'exploitation s'attend à trouver des données Unicode. Par conséquent, les colonnes
non Unicode doivent souvent être converties lorsque vous affichez des données ou
utilisez les services du système d'exploitation.
Lorsque vous traitez un format de données DBCS natif, il peut falloir plus de temps
pour charger la quantité accrue de données.
Si vous travaillez avec plusieurs instances ou produits de serveur de base de données
ou si vous échangez des données avec d'autres applications, le nombre de conversions
peut affecter les performances.
Si vous traitez des langues asiatiques, Unicode est plus rapide que la page de code
DBCS spécifique à la langue. La raison en est que les données DBCS n'ont pas de
largeur fixe : il s'agit d'un mélange de caractères à deux octets et un octet.
Si vous traitez des langues non asiatiques, le tri des données Unicode peut être plus
lent que le tri de données non Unicode.
L'ordre binaire est l'ordre de tri le plus rapide et il est sensible à la casse, mais il peut
produire des ordres de tri imprévus. Si vous choisissez un ordre de tri binaire, les
options sensibles à la casse, aux accents, aux caractères kana (caractères japonais) et à
la largeur ne sont pas disponibles.
Important Pour évaluer les performances de façon réaliste, vous devez tester les deux
scénarios : Unicode et non Unicode.
Migration d'informations de métadonnées dans les tables
système
Les tables système dans SQL Server 2005 enregistrent toutes les données, y compris les
identificateurs d'objets, comme Unicode. Ceci réduit les problèmes qui peuvent survenir avec
les différences de classements entre les bases de données et les colonnes.
Si vous migrez de SQL Server 2000 à SQL Server 2005, le seul changement significatif réside
dans le fait que SQL Server 2000 utilise la norme Unicode 2.0 pour la liste de caractères
valides dans les identificateurs, alors que SQL Server 2005 prend en charge la norme Unicode
version 3.2.
Vous pouvez mettre directement à niveau des instances de SQL Server 2000 Service Pack 3
(SP3) ou ultérieures et des instances de SQL Server 7.0 SP4 ou ultérieures vers
SQL Server 2005. Vous pouvez exécuter la plupart des opérations de mise à niveau par le
biais du programme d'installation. Toutefois, certains composants prennent en charge ou
nécessitent la migration des applications ou des solutions une fois l'installation terminée.
Classements
L'ordre de tri est un élément critique mais souvent négligé de la définition de bases de
données. Les utilisateurs ont tendance à supposer que le tri suit obligatoirement leur propre
alphabet. Cependant, certaines langues, telles que le grec, le russe et le thaï utilisent des
alphabets différents. Certaines langues, comme le japonais, utilisent plusieurs alphabets, avec
des règles de tri complexes. Même dans les langues européennes, il existe une grande
différence dans la façon dont sont gérés les caractères individuels. Par exemple, les
utilisateurs espagnols s'attendent à ce que la combinaison de lettres « ch » soit triée en tant
que caractère unique après la lettre « h ».
Le tri de base fonctionne sur les classements, qui contrôlent les ordres de tri, entre autres
comportements. Le tri peut être optimisé par la création d'index.
Le tri fonctionne conjointement avec une technique appelée normalisation de chaîne. Ce type
de normalisation diffère du sens du mot auquel les développeurs de base de données sont
habitués. La normalisation de chaîne désigne une méthode de comparaison de deux chaînes
afin de pouvoir les trier : Par exemple, vous pouvez spécifier si des types de caractères kana
différents doivent être traités comme des équivalents, ou si les accents doivent être ignorés.
Pour les colonnes non Unicode, le classement prend un second sens très important : le
classement spécifie la page de code pour les données et détermine donc quels caractères
peuvent être représentés. Les données peuvent être déplacées entre des colonnes Unicode sans
nécessiter de conversion spéciale ou de mappages de caractères. Les données déplacées entre
les colonnes non Unicode sont fréquemment tronquées ou corrompues, voire ne peuvent pas
être affichées du tout.
Classements dans SQL Server 6.5 et versions antérieures
Dans SQL Server 6.5 et les versions antérieures, les classements ont été utilisés pour spécifier
la page de code à utiliser pour la langue en général. Les différents ordres de tri, notamment,
étaient soumis à de nombreuses restrictions. Par exemple, vous pouviez uniquement prendre
en charge des langues d'Europe occidentale si vous utilisiez Latin-1.Les classements
limitaient également le nombre de paramètres régionaux que vous pouviez représenter dans
une seule instance de SQL Server. En d'autres termes, vous ne pouviez enregistrer ou afficher
que la langue utilisée dans une zone géographique spécifique. Pour utiliser une langue
différente, vous deviez configurer une base de données à part, voire un serveur distinct.
Ces problèmes concernent également le classement de champs non Unicode dans les versions
ultérieures de SQL Server.
Classements mis à jour dans SQL Server 7.0
SQL Server 7.0 fournissait un classement Unicode et un classement non Unicode par serveur.
Les classements non Unicode étaient définis comme une combinaison d'une page de code et
d'un ordre de tri. Souvent, chaque page de code peut prendre en charge plus d'un ordre de tri.
Par exemple, les langues latines autorisent généralement un tri sensible à la casse et un tri non
sensible à la casse. Le chinois simplifié autorise le tri par nombre de trais et le tri phonétique.
Dans un classement Unicode, n'importe quel caractère de n'importe quelle langue peut être
inclus dans une colonne, et les divers classements fournis étaient conçus pour garantir que
toutes les différences spécifiques au classement sont gérées convenablement. En d'autres
termes, vous choisissez la « meilleure option » pour donner aux utilisateurs ce qu'ils attendent.
Par exemple, le classement Unicode général vous permet de trier les données en persan.
Un classement Unicode consiste en un paramètre régional et en plusieurs styles de
comparaison. Les paramètres régionaux sont habituellement nommés d'après les pays ou les
régions culturelles. Ils trient les caractères selon la norme en vigueur dans cette région. Le
classement Unicode fournit toujours un ordre de tri pour tous les caractères de la norme
Unicode, mais le paramètre régional a toujours priorité. Tout paramètre régional ne possédant
pas de classement Unicode unique pris en charge doit utiliser le classement Unicode général.
L'ordre de tri Unicode général gère correctement non seulement les données, mais également
le tri de données en afrikaans, albanais, anglais, arabe, basque, biélorusse, bulgare, féroïen,
persan, géorgien (traditionnel), grec, hébreu, hindi, indonésien, malais, russe, serbe, swahili et
urdu.
L'une des modifications importantes apportées à SQL Server 7.0 résidait dans l'apport d'un
modèle indépendant du système d'exploitation pour la comparaison de chaîne, de sorte que les
classements entre tous les systèmes d'exploitation (de Windows 95 à Windows 2000) soient
cohérents. Ce code de comparaison de chaîne était basé sur le même code que celui qu'utilise
Windows 2000 pour sa propre normalisation de chaîne, et il est encapsulé de manière à être
identique sur tous les ordinateurs et dans toutes les versions de SQL Server.
Classements dans SQL Server 2000
Dans SQL Server 2000, le modèle de classement a été modifié pour éliminer des incohérences
entre les deux différents systèmes de classement : les classements Windows et les classements
SQL. Un modèle plus flexible était nécessaire pour gérer toutes les nouvelles exigences des
classements. De nouveaux classements étaient également nécessaires dans SQL Server 2000
pour gérer la page de code des colonnes non Unicode.
Pour répondre à ces besoins, un modèle cohérent unique a été conçu pour gérer les tris
Unicode et non Unicode. Chacun des classements a été associé à des suffixes qui permettent
de définir si le classement est sensible à la casse, aux accents, à la largeur ou aux caractères
kana. L'annexe A contient un tableau répertoriant les suffixes. Ces 17 suffixes, combinés de
manière adéquate aux 40 langues prises en charge dans SQL Server 2000, ont créé un total de
680 classements Windows.
Les noms de langue utilisés pour les classements étaient arbitraires et ont été choisis de
manière à représenter chaque page de code unique prise en charge pour les données non
Unicode et un ordre de tri pour toutes les données. Dans de nombreux cas, plusieurs langues
pouvaient être entièrement représentées sur une seule page de code ou gérées par le même
ordre de tri qu'une autre langue. Ces langues supplémentaires ont alors été supprimées de la
liste.
Classements dans SQL Server 2005
SQL Server 2005 prend en charge toutes les langues prises en charge par les systèmes
d'exploitation Microsoft Windows. SQL Server 2005 a donc ajouté une prise en charge pour
les classements nouveaux et mis à jour dans Windows Server 2003 et Windows XP. (Ces
classements sont installés dans le cadre de l'installation de SQL Server 2005. Vous contrôlez
le choix du classement pour le serveur et la base de données pendant l'installation. Les mises à
jour du système d'exploitation n'affectent pas les classements utilisés dans SQL Server).
Les classements d'Extrême-Orient, qui prennent en charge des caractères supplémentaires,
représentaient un élément important des nouveaux classements. Une prise en charge a
également été ajoutée pour la comparaison de chaînes de caractères supplémentaires, basée
sur les points de code, et un indicateur binaire (BIN2) a été introduit pour autoriser de
véritables comparaisons de points de code.
Les classements binaires trient et comparent les données dans SQL Server en fonction du
modèle binaire de chaque caractère. Chaque classement binaire dans SQL Server s'associe à
un paramètre régional de langue spécifique et à une page de code ANSI, et chacun exécute
des tris de données sensibles à la casse et aux accents. Les classements binaires offrent les tris
de données les plus rapides.
L'option Binaire (_BIN) trie et compare des données dans les tables SQL Server en fonction
des modèles binaires définis pour chaque caractère. L'ordre de tri binaire tient compte de la
casse et des accents. Il est également l'ordre de tri le plus rapide. Si cette option n'est pas
sélectionnée, SQL Server suit les règles de tri et de comparaison définies dans les
dictionnaires de la langue ou l'alphabet associé.
L'option de point de code Binaire (_BIN2) trie et compare les données dans les tables
SQL Server en fonction des points de code Unicode pour les données Unicode. Pour les
données non Unicode, le point de code Binary utilisera des comparaisons identiques aux tris
binaires. L'avantage de l'utilisation d'un ordre de tri par point de code Binary est qu'il n'est pas
nécessaire de retrier les données dans les applications qui comparent des données SQL Server
triées. Par conséquent, un ordre de tri par point de code Binary facilite le développement
d'applications et offre des possibilités d'augmentation des performances.
L'annexe E contient une liste des classements mis à jour dans SQL Server 2005. À moins que
vous n'ayez besoin d'une compatibilité ascendante avec SQL Server 2000 ou des versions
précédentes, il est préférable d'utiliser les classements mis à jour.
Les classements dans SQL Server 2005 incluent les types de classement suivants : les
classements Windows et les classements SQL.
Classements Windows
Les classements Windows définissent des règles pour enregistrer les données de caractères en
fonction d'un paramètre régional Windows associé. (Il existe plus de paramètres régionaux
Windows que de classements Windows dans SQL Server). Les règles de base du classement
Windows spécifient quel alphabet ou langue est utilisé en cas d'application du tri par
dictionnaire, de même que la page de code utilisée pour enregistrer les données de caractères
non Unicode. Dans SQL Server, les classements Windows sont combinés avec une série de
suffixes pour définir précisément les règles de tri et de comparaison en fonction de la
sensibilité à la casse, aux accents, aux kana et à la largeur. Le nom de classement Windows
complet est composé de la désignation du classement et des styles de comparaison.
Dans un classement Windows, la comparaison et le tri de données non Unicode sont mis en
œuvre en utilisant le même algorithme que pour les données Unicode. Ceci assure une
cohérence entre les types de données dans SQL Server et permet également aux développeurs
de trier des chaînes dans leurs applications en utilisant les mêmes règles que celles utilisées
par SQL Server, c'est-à-dire en appelant la fonction CompareStringW de l'API Microsoft
Win32.
Classements binaires
Les classements binaires trient les données en fonction de la séquence de valeurs codées
définie par le paramètre régional et le type de données. Un classement binaire dans
SQL Server définit le paramètre régional linguistique et la page de code ANSI à utiliser, en
appliquant un ordre de tri binaire. Les classements binaires sont utiles pour améliorer les
performances des applications en raison de leur relative simplicité. Pour les types de données
non Unicode, les comparaisons de données sont basées sur les points de code définis dans la
page de code ANSI. Pour les types de données Unicode, les comparaisons de données sont
basées sur les points de code Unicode. Pour les classements binaires sur les types de données
Unicode, le paramètre régional n'est pas pris en compte dans le tri des données. Par exemple,
Latin_1_General_BIN et Japanese_BIN2 utilisés sur des données Unicode produisent des
résultats de tri identiques. La raison en est que le classement compare les données Unicode en
tant qu'Unicode et compare des données non Unicode en tant que binaires.
Dans SQL Server 2000, les classements binaires exécutaient une comparaison point de code à
point de code incomplète pour les données Unicode. Le premier caractère était comparé en
tant que WCHAR, suivi d'une comparaison octet par octet. Par souci de compatibilité
ascendante, la sémantique de classement binaire existante ne sera pas modifiée.
Les classements binaires dans SQL Server 2005 incluent à la fois le classement BIN
précédent et une nouvelle série de classements de comparaison de point de code pure. Les
clients peuvent choisir de migrer vers les nouveaux classements binaires pour profiter de
vraies comparaisons de point de code, et ils doivent utiliser les nouveaux classements binaires
quand ils développent de nouvelles applications. Le nouveau suffixe BIN2 identifie les noms
de classements qui implémentent la nouvelle sémantique de classement de point de code. De
plus, un nouvel indicateur de comparaison correspondant à BIN2 a été ajouté pour le nouveau
tri binaire.
SQL Server recommande automatiquement un classement par défaut en fonction des
paramètres régionaux du système. Vous ne devez modifier les paramètres pour classement
Windows par défaut que si votre installation SQL Server doit reprendre les paramètres de
classement utilisés par une autre instance de SQL Server, ou si le paramètre de classement
doit correspondre aux paramètres régionaux du système Windows d'un autre ordinateur.
Si vous avez besoin de gérer des caractères supplémentaires, changez le classement par défaut
pour l'un des nouveaux classements, qui prennent en charge les opérations de tri et de
comparaison sur les caractères supplémentaires. Ces comparaisons sont basées sur les points
de code uniquement, pas sur d'autres méthodes logiques d'un point de vue linguistique. Seules
les versions de classement 90, indiquées par le suffixe 90 ajouté à leurs noms, prennent en
charge ces opérations. Par exemple, au lieu du classement Japanese, utilisez Japanese_90. Si
vous n'utilisez pas un classement compatible avec les caractères supplémentaires, soyez
prudent lorsque vous utilisez des caractères supplémentaires dans les opérations telles que
ORDER BY, GROUP BY et DISTINCT, en particulier lorsque des caractères
supplémentaires et non supplémentaires sont inclus dans la même opération.
Classements SQL Server
Les classements SQL Server fournissent une compatibilité d'ordre de tri avec les versions
précédentes de SQL Server. (Pour une liste complète des classements SQL Server, consultez
la section Nom de classement SQL dans la documentation en ligne de SQL Server 2005). Les
classements SQL Server sont basés sur les ordres de tri SQL Server hérités pour les données
non Unicode (par exemple, les types de données char et varchar) définies par SQL Server.
Les règles de tri par dictionnaire des données non Unicode ne sont pas compatibles avec la
routine de tri fournie par les systèmes d'exploitation Windows, mais le tri de données Unicode
est compatible avec une version particulière des règles de tri de Windows. Les classements
SQL Server utilisant des règles de comparaison différentes pour les données non Unicode et
pour les données Unicode, vous pourriez obtenir des résultats différents pour les mêmes
comparaisons de données, en fonction du type de données sous-jacent.
Lorsque vous mettez à niveau une instance de SQL Server, vous pouvez spécifier des
classements SQL Server pour la compatibilité avec les instances existantes de SQL Server.
Comme le classement par défaut pour une instance de SQL Server est défini pendant
l'installation, il est important de spécifier soigneusement les paramètres de classement
lorsque :



votre code d'application dépend dans une certaine mesure du comportement des
classements SQL Server antérieurs ;
vous comptez utiliser la réplication SQL Server 2005 avec des installations existantes
de SQL Server 6.5 ou SQL Server 7.0 ;
vous devez enregistrer des données de caractères qui reflètent plusieurs langues.
Si vous avez un mélange de colonnes Unicode et non Unicode dans votre base de données,
vous devez utiliser en priorité les classements Windows. Les classements Windows
appliquent des règles de tri de base Unicode aux données Unicode et non Unicode. Cela
signifie que SQL Server convertit en interne les données non Unicode en Unicode pour
effectuer les opérations de comparaison. Ceci assure la cohérence dans les types de données
dans SQL Server et permet également aux développeurs de trier des chaînes de leurs
applications qui utilisent les mêmes règles que SQL Server.
Les classements SQL, d'autre part, appliquent des règles de tri non Unicode aux données non
Unicode et des règles de tri Unicode aux données Unicode, en utilisant un classement
Windows correspondant pour les données Unicode. Cette différence peut provoquer des
incohérences de résultats pour les comparaisons de caractères identiques. Donc, si votre base
de données contient à la fois des colonnes Unicode et non Unicode, celles-ci doivent toutes
être définies en utilisant les classements Windows de manière à utiliser les mêmes règles de
tri sur les données Unicode et non Unicode.
Compatibilité ascendante dans les classements
Le classement binaire BIN fourni dans SQL Server 2000 effectuait une comparaison de point
de code à point de code incomplète pour les données Unicode. Ces classements binaires
comparaient le premier caractère en tant que WCHAR, suivi d'une comparaison octet par
octet. Ceci pouvait provoquer un tri imprévu des données de caractères Unicode.
Pour garantir la compatibilité ascendante, la sémantique de classement binaire existante ne
sera pas modifiée. Cependant, cette fonctionnalité peut avoir été remplacée par les nouveaux
classements. L'annexe répertorie les classements qui ont été conservés pour assurer la
compatibilité ascendante avec SQL Server 2000 ou SQL Server 7.0.
Pour obtenir des informations sur les classements dans une base de données, vous pouvez
utiliser les vues système suivantes :
Vue Catalogue
sys.databases
sys.columns
COLLATIONPROPERTY
Description
Renvoie des informations sur le classement
d'une base de données.
Renvoie des informations sur le classement
d'une colonne d'une table ou d'une vue.
Renvoie des informations sur les classements
dans SQL Server 2005.
Vous pouvez transmettre la valeur CodePage,
ou LCID, qui renvoie les paramètres
d'identification locaux de Windows, ou Null
pour les classements SQL.
fn_helpcollations
Vous pouvez également spécifier Windows
ComparisonStyle (renvoie Null pour les
classements Binary et SQL). Vous pouvez
utiliser ComparisonStyle pour vérifier qu'il
existe une équivalence entre la normalisation
de chaîne dans Windows et dans SQL Server
pour le classement Windows.
Renvoie une liste des classements disponibles
dans SQL Server 2005.
SELECT * FROM ::fn_helpcollations()
SERVERPROPERTY
Dans SQL Server 2005, cette requête renvoie
1 011 classements. (Dans SQL Server 2000,
753 classements.)
Renvoie le classement associé au serveur.
SELECT CONVERT(char,
SERVERPROPERTY('collation'))
DATABASEPROPERTYEX
Détermine le classement d'une base de
données, par exemple :
SELECT CONVERT(char,
DATABASEPROPERTYEX('pubs',
'collation'))
Il n'est pas possible d'ajouter des classements supplémentaires, à moins qu'ils ne le soient dans
des Service Packs ou de futures versions.
Classements et tri de données
En règle générale, chaque classement défini dans SQL Server sur une colonne Unicode triera
tous les caractères Unicode définis. Cependant, il existe de nombreux classements différents,
car les méthodes possibles de tri des données sont elles-mêmes très diverses. Citons par
exemple le tri moderne du géorgien. Bien que le tri traditionnel du texte géorgien place tous
les caractères dans un ordre spécifique, il est courant dans l'usage moderne de placer certains
caractères rarement utilisés à la fin. Ces caractères sont HE (), HEI (), WE () et HAR (). Ainsi,
il existe deux façons de trier l'alphabet géorgien : traditionnel et moderne.
Figure 4. Ordre de tri traditionnel du géorgien
Figure 5. Ordre de tri moderne du géorgien
L'existence de ce classement n'empêche pas le tri des autres données Unicode selon l'ordre de
tri fourni dans le classement Latin1_General. Tous les classements, en fait, trient le géorgien
sous la forme traditionnelle, à la seule exception des classements Georgian_Modern_Sort. En
d'autres termes, les mêmes règles générales s'appliquent à tous les classements ; seules les
exceptions peuvent changer entre les classements.
Niveaux de classement
SQL Server 2005 prend en charge la configuration des classements aux niveaux suivants
d'une instance de SQL Server 2005 :




Niveau serveur
Niveau base de données
Niveau colonne
Niveau expression
Cette section explique ces niveaux de classement et comment ils interagissent lorsque
plusieurs classements sont utilisés.
Classements spécifiés au niveau du serveur
Le classement par défaut d'une instance de SQL Server est déterminé pendant l'installation. Le
classement par défaut de l'instance devient également le classement par défaut des bases de
données système. Après l'affectation d'un classement à n'importe quel objet (autre qu'une
colonne ou une base de données), vous ne pouvez pas modifier le classement à moins de
supprimer et de recréer l'objet. Au lieu de modifier le classement par défaut d'une instance de
SQL Server, vous pouvez spécifier le classement lorsque vous créez une nouvelle base de
données ou colonne de base de données.
Dans les versions précédentes, le classement était toujours défini au niveau du serveur et, dans
de nombreux cas, il s'agissait du seul classement que vous ayez jamais besoin de définir. Le
classement serveur sert de classement par défaut lors de la création d'une nouvelle base de
données sur le serveur, à moins que vous ne définissiez explicitement le classement au niveau
de la base de données. Dans la mesure où chaque base de données possède son propre
classement, il n'est fait référence au classement de niveau serveur que lors de la création
initiale de la base de données.
Dans SQL Server 2000, vous pouviez modifier le classement par défaut pour le serveur sans
réexécuter le programme d'installation, en utilisant l'utilitaire de reconstruction de base de
données principale (Rebuild Master, RebuildM.exe), situé dans le répertoire Program
Files\Microsoft SQL Server\80\Tools\BINN. Pour plus d'informations, consultez la section
Comment reconstruire la base de données principale (utilitaire Rebuild Master) dans la
documentation en ligne de SQL Server 2005 pour SQL Server 2000. Dans SQL Server 2005,
cet utilitaire n'est pas pris en charge. Vous utilisez à sa place l'option REBUILDDATABASE
dans Setup.exe. Toutefois, dans la mesure où le classement du serveur n'est pas souvent
utilisé, vous pouvez spécifier un classement par défaut pour chaque nouvelle base de données
que vous créez, au lieu de modifier le classement par défaut d'une instance de
SQL Server 2005.
Si vous devez modifier le classement par défaut pour une instance de SQL Server 2005, vous
devez d'abord écrire le script ou sauvegarder votre base de données, supprimer toutes les
bases de données utilisateur, puis reconstruire la base de données principale (en spécifiant le
nouveau classement dans la propriété SQLCOLLATION de la commande d'installation,
comme suit :
start /wait setup.exe /qb INSTANCENAME=MSSQLSERVER REINSTALL=SQL_Engine
REBUILDDATABASE=1 SAPWD=test SQLCOLLATION=SQL_Latin1_General_CP1_CI_AI).
Classements au niveau de la base de données
Lors de la création d'une base de données, vous pouvez utiliser la clause COLLATE de
l'instruction CREATE DATABASE pour spécifier le classement par défaut de la base de
données. Si aucun classement n'est spécifié pendant la création de base de données, elle reçoit
le classement par défaut de la base de données modèle. Le classement par défaut de la base de
données modèle est identique au classement par défaut de l'instance de SQL Server.
Chaque base de données peut avoir un classement unique, avec l'ordre de tri défini au niveau
de la base de données. La figure 6 illustre le mode de définition du classement avec
SQL Server Management Studio.
Figure 6. Définition du classement de base de données en utilisant l'onglet Options de la
fenêtre de Propriétés de la base de données (Cliquer sur l'image pour l'agrandir)
Vous pouvez également déterminer l'ordre de classement en utilisant Transact-SQL. Par
exemple, pour créer une nouvelle base de données qui utilise l'ordre de tri tchèque et qui
respecte la casse et les accents, utilisez une instruction telle que :
USE master
GO
CREATE DATABASE Products
ON
( NAME = products_dat,
FILENAME = 'c:\program files\microsoft sql
server\mssql\data\products.mdf' )
COLLATE Czech_CS_AS
GO
Dans SQL Server 2005, vous pouvez également modifier le classement d'une base de données
existante à l'aide de SQL Server Management Studio. Dans SQL Server 2000, cette
fonctionnalité n'était pas disponible dans SQL Server Enterprise Manager. Vous deviez
utiliser l'instruction ALTER DATABASE. Par exemple, l'instruction suivante modifie le
classement de la base de données Products de Czech_CS_AS en Czech_CI_AI (respect de la
casse et des accents à non-respect de la casse et des accents).
ALTER DATABASE Products
COLLATE Czech_CI_AI
Éléments à prendre en compte avant de modifier le classement d'une base de données
Si vous avez des données dans un champ texte, varchar ou char et qu'il n'existe pas de
classement explicite sur la colonne, la modification du classement de la base de données
change la façon dont est interprété le codage des données, ce qui se traduit par une certaine
forme d'altération pour tous les caractères au-delà de la plage ASCII.
Par conséquent, évitez de modifier le classement de toute base de données contenant des
données de texte non Unicode, à moins que les données ne soient enregistrées dans des
colonnes possédant leurs propres paramètres de classement explicites.
Pour qu'il soit possible de modifier le classement d'une base de données, toutes les conditions
suivantes doivent être respectées :



Personne d'autre ne peut être en train d'utiliser la base de données.
Aucun objet lié au schéma ne doit dépendre du classement de la base de données. Les
objets liés au schéma sont notamment :
 les fonctions et vues définies par l'utilisateur, créées avec
SCHEMABINDING ;
 les colonnes calculées ;
 les contraintes CHECK ;
 les fonctions de table définie qui renvoient des tables avec des colonnes de
caractères et des classements hérités du classement de base de données par
défaut.
La modification du classement de la base de données ne crée pas de doublon dans les
noms système. Si des doublons sont détectés, une erreur est générée et l'opération de
modification du classement échoue.
Les objets susceptibles de causer de telles duplications incluent :


les noms d'objet (tels que procedure, table, trigger ou view) ;
les noms de schéma (tels que group, role ou user) ;




les noms de type scalaire (tels que system et les types définis par l'utilisateur) ;
les noms de catalogue en texte intégral ;
les noms de colonne ou de paramètre dans un objet ;
les noms d'index dans une table.
Par exemple, supposons que votre base de données contient deux tables nommées Table1 et
TABLE1 et que vous essayez de modifier le classement de French_CS_AS (respect de la
casse et des accents) en French_CI_AS (non-respect de la casse et des accents). Avec le
premier classement, il est possible d'avoir deux tables. Cependant, le passage au deuxième
classement génère des doublons.
Classements spécifiés au niveau de la colonne
Dans SQL Server 2005, vous pouvez spécifier le classement du texte dans une colonne
particulière. Cela peut être très utile, par exemple, si vous avez besoin de forcer la sensibilité à
la casse pour une colonne de mots de passe. Les autres scénarios dans lesquels les classements
au niveau des colonnes pourraient être utiles impliquent plusieurs langues dans la même table.
Par exemple, il faudra parfois utiliser Unicode avec le classement Latin1_General dans la
colonne des noms de clients pour activer le tri pertinent à une variété de noms, tandis que la
colonne de la gamme de produits peut déjà contenir du grec, et pour cette colonne, il peut être
judicieux d'utiliser un classement Greek. La figure 7 montre comment choisir un classement
et définir les options d'ordre de tri pendant la conception de la table.
Figure 7. Spécification d'un classement
Si vous n'avez pas précédemment défini un classement sur la colonne, lorsque vous cliquez
sur cette dernière, la boîte de dialogue affiche <base de données par défaut> en tant que
propriété Classement de la colonne. Pour modifier le classement, cliquez sur le bouton
représenté par des points de suspension (...). Vous ouvrez ainsi la boîte de dialogue
Classement dans laquelle vous sélectionnez un classement Windows ou un classement
SQL Server et définissez les options de tri.
Lorsque vous sélectionnez un classement Windows, vous pouvez spécifier si le classement est
sensible à la casse, aux accents, au type de kana et à la largeur.
Vous pouvez également déterminer les classements au niveau des colonnes à l'aide de
Transact-SQL en ajoutant une clause COLLATE à la définition de la colonne dans
l'instruction CREATE TABLE.
L'exemple suivant montre comment utiliser Transact-SQL pour spécifier un classement pour
la colonne de description de la fonction qui est définie sur Arabe et qui est insensible à la
casse, aux accents et au type de kana.
CREATE TABLE jobs
(
job_id smallint
IDENTITY(1,1)
PRIMARY KEY CLUSTERED,
job_desc varchar(50)
COLLATE Arabic_CI_AI_KS
NOT NULL
DEFAULT 'New Position - title not formalized yet',
)
Vous pouvez également utiliser l'instruction ALTER TABLE pour modifier le classement au
niveau d'une colonne (mais pas d'une colonne ntext ou text). Si la clause COLLATE n'est pas
spécifiée, la modification d'un type de données entraîne la modification du classement de la
colonne qui passe au classement par défaut de la base de données.
Dans SQL Server 2005, vous pouvez également modifier le classement par programmation en
utilisant la propriété column.collation dans les objets SMO (SQL Management Objects).
La clause COLLATE peut être utilisée pour modifier le classement des colonnes des types de
données char, varchar, nchar et nvarchar uniquement. Pour modifier le classement d'une
colonne de type de données d'alias défini par l'utilisateur, vous devez exécuter des instructions
ALTER TABLE séparées pour changer la colonne en type de données de système SQL Server
et modifier son classement, puis modifier à nouveau cette colonne et la ramener à un type de
données d'alias.
ALTER COLUMN ne peut pas avoir une modification de classement si une ou plusieurs des
conditions suivantes existent :


Si une contrainte CHECK ou FOREIGN KEY ou une colonne calculée référence la
colonne qui est modifiée.
Si des index, statistiques ou index en texte intégral sont créés sur la colonne. Les
statistiques créées automatiquement sur la colonne modifiée sont supprimées si le
classement de la colonne est modifié.

Si un affichage ou une fonction lié au schéma-référence la colonne.
Vous pouvez insérer ou mettre à jour des valeurs dans une colonne de texte dont le classement
est différent de la page de code du classement par défaut de la base de données. SQL Server
convertit implicitement les valeurs au classement de la colonne.
Classements spécifiés dans les expressions
Les classements au niveau des expressions sont définis au moment où une instruction est
exécutée ; ils affectent la façon dont un ensemble de résultats est renvoyé. Ceci permet de trier
les résultats de sorte que la clause ORDER BY soit spécifique à la langue.
Pendant l'installation de SQL Server, vous êtes invité à sélectionner les classements Windows
ou les classements binaires. Votre choix de classement a un effet sur la comparaison des
données et l'ordre de tri de votre instance de Microsoft SQL Server.
Il peut y avoir de nombreux cas dans lesquels vous devrez afficher des données à l'intention
de personnes de pays différents et souhaiterez un tri approprié pour chaque pays. Dans les
versions 2000 et 2005 de SQL Server, vous pouvez spécifier des classements dans les
expressions. Cette puissante fonctionnalité vous permet d'organiser le tri de sorte que la clause
ORDER BY soit spécifique à la langue.
Par exemple, la requête suivante sur la base de données AdventureWorks trie la table
Person.Address en fonction de la ville figurant dans l'adresse. L'ordre de tri lituanien illustre
bien les différences de classements parce que les règles concernant le tri de la lettre Y sont
extrêmement remarquables.
SELECT *
FROM Person.Address
ORDER BY City COLLATE Lithuanian_CI_AI
L'exemple suivant suppose que Table1 n'a pas de classement explicite au niveau des
colonnes. Dans ce cas, les deux colonnes sont comparées en utilisant l'ordre de tri turc.
SELECT
*
FROM Table1
WHERE Field1 = Field2 COLLATE Turkish_ci_ai
Pour savoir comment les classements sont utilisés dans les comparaisons, consultez la section
« Règles de priorité des classements », plus loin dans ce document.
Mot-clé COLLATE
Un classement peut être défini au niveau de la base de données, au niveau des colonnes ou
dans une expression. Pour spécifier le classement d'une base de données, d'une colonne ou
d'une expression de caractères, utilisez la syntaxe suivante :
COLLATE [<Windows_Collation_name>|<SQL_Collation_Name]
Si la colonne n'est pas définie à l'aide d'un type de données Unicode (ntext, nvarchar,
nvarchar(max)), nchar), le classement est converti en page de code.
Le mot-clé COLLATE vous permet d'utiliser les deux types de classements suivants :
Classements Windows
Ils sont définis par Windows. Vous pouvez modifier des options pour spécifier la sensibilité à
la casse, aux accents, au kana et à la largeur, et vous pouvez choisir un ordre de tri binaire.
Classements SQL
Ces classements sont proposés à des fins de compatibilité ascendante. Vous ne pouvez pas
configurer l'ordre de tri.
Essayez d'utiliser les classements Windows autant que possible. L'exemple suivant présente
une liste d'indicatifs et de noms de pays, et montre comment le comportement du tri peut
changer en fonction du classement. La partie supérieure de la fenêtre des requêtes affiche la
liste triée par les classements par défaut ; la partie inférieure de la fenêtre affiche les mêmes
données triées par le classement lituanien.
Dans le classement par défaut, affiché en premier, Y se situe entre X et Z. Dans le classement
lituanien, le classement suivant, Y est entre I et J.
Figure 8. Effet du classement lituanien sur le tri (Cliquez sur l'image pour l'agrandir)
Règles de priorité des classements
Étant donné que vous pouvez spécifier des classements au niveau du serveur, de la base de
données, des colonnes et des expressions, il est important de comprendre l'interaction qui
existe entre les classements. La priorité de classement détermine la façon dont les expressions
renvoyant à une chaîne de caractères sont assemblées et le classement utilisé par les
opérateurs qui emploient des entrées de chaînes de caractères mais ne renvoient pas de chaîne
de caractères, tels que LIKE et IN.
Les règles de priorité de classement de SQL Server 2005 s'appliquent uniquement aux
données de types chaîne de caractères char, varchar, text, nchar, nvarchar et ntext. Les
objets qui ont d'autres types de données ne participent pas aux évaluations de classement.
Les opérateurs de comparaison et les opérateurs MAX, MIN, BETWEEN, LIKE et IN sont
sensibles au classement. La chaîne utilisée par les opérateurs reçoit l'étiquette de classement
de l'opérande assorti de la priorité la plus élevée. L'opérateur UNION est également sensible
au classement, et tous les opérandes de chaîne et le résultat final reçoivent le classement de
l'opérande assorti de la priorité la plus élevée. La priorité de classement des opérandes
UNION et les résultats sont évalués par colonne.
L'opérateur d'attribution est sensible au classement, et la bonne expression est convertie au
classement de gauche.
L'opérateur de concaténation de chaîne est sensible au classement. Les deux opérandes de
chaîne et le résultat reçoivent l'étiquette de classement de l'opérande assorti de la plus priorité
la plus élevée. Les opérateurs UNION ALL et CASE ne sont pas sensibles au classement, et
tous les opérandes de chaîne et les résultats finaux reçoivent l'étiquette de classement de
l'opérande assorti de la priorité la plus élevée. La priorité de classement des opérandes
UNION ALL et les résultats sont évalués par colonne.
Étant donné que les objets peuvent avoir des classements différents à divers niveaux,
SQL Server 2005 introduit les étiquettes de classement pour vous aider à gérer l'interaction
complexe des classements. Une étiquette de classement nomme une catégorie d'objets qui
peuvent prendre un classement. Les règles de classement sont décrites en termes d'interactions
entre les étiquettes de classement.
Si une expression référence seulement un objet de chaîne de caractères, l'étiquette de
classement de l'objet référencé est utilisée. Si l'expression référence deux expressions
d'opérande qui ont la même étiquette de classement, celle-ci devient l'étiquette de classement
de l'expression d'opérande.
Si une expression complexe référence deux expressions d'opérande avec des classements
différents, l'étiquette de classement du résultat final utilise une série de règles pour déterminer
la priorité des classements. Pour plus d'informations, consultez la section Priorité des
classements (Transact-SQL) dans la documentation en ligne de SQL Server 2005.
La liste suivante décrit les différents types d'étiquettes de classement. Cette liste est suivie par
un tableau qui résume les interactions possibles des étiquettes de classement.
Explicit
Un classement est explicitement défini pour une expression donnée ou explicitement converti
à un classement spécifique (X) en utilisant une clause COLLATE dans l'expression.
Implicit
Une colonne est référencée. Même si un classement est explicitement affecté à une colonne à
l'aide d'une clause COLLATE dans l'instruction CREATE TABLE ou CREATE VIEW, une
référence de colonne est classée comme implicite.
Coercible-Default
Le classement au niveau des bases de données est utilisé pour n'importe quelle variable de
chaîne de caractères Transact-SQL, paramètre, valeur littérale, sortie d'une fonction intégrée à
un catalogue ou sortie d'une fonction intégrée qui n'accepte pas les entrées de chaînes mais
produit une sortie de chaînes.
Si l'objet est déclaré dans une fonction définie par l'utilisateur, une procédure enregistrée ou
un déclencheur, l'objet reçoit le classement par défaut de la base de données dans laquelle la
fonction, la procédure enregistrée ou le déclencheur est créé. Si l'objet est déclaré dans un lot,
il reçoit le classement par défaut de la base de données actuelle pour la connexion.
No Collation
Lorsque la valeur d'une expression est le résultat d'une opération entre deux chaînes qui ont
des classements contradictoires de l'étiquette de classement implicite, le résultat de
l'expression est défini comme n'ayant pas de classement.
Explicit C1
Implicit C1
Run-time Error Explicit C1
Explicit C2
Explicit C2
No Collation
Implicit C1
Explicit C2
Implicit C2
Par défaut
No Collation
No Collation Explicit C2
Par défaut
Explicit C1
Implicit C1
Par défaut
No Collation
No Collation
Explicit C1
No Collation
No Collation
No Collation
Ce tableau montre que la seule fois où SQL Server ne peut pas traiter une expression est
lorsque vous définissez explicitement deux classements différents et contradictoires ou
lorsque vous essayez de comparer deux éléments et qu'aucun point commun pour la
comparaison ne peut être trouvé.
Par exemple, examinons l'instruction Transact-SQL suivante servant à créer une table :
CREATE TABLE TestTab (
id int,
GreekCol nvarchar(10) COLLATE greek_ci_as,
LatinCol nvarchar(10) COLLATE latin1_general_cs_as
)
INSERT TestTab VALUES (1, N'A', N'a')
GO
Cette instruction crée une table comprenant une colonne utilisant un classement Greek
insensible à la casse et sensible aux accents et une deuxième colonne utilisant un classement
General Latin1 sensible à la casse et aux accents.
Vous pouvez essayer d'utiliser une requête pour comparer les deux explicitement :
SELECT *
FROM TestTab
WHERE GreekCol = LatinCol
Cependant, la requête renvoie une erreur :
Msg 468, Level 16, State 9, Line 1
Cannot resolve the collation conflict between "Latin1_General_CS_AS"
and "Greek_CI_AS" in the equal to operation.
L'erreur survient parce que le serveur ne peut pas comparer deux segments de texte qui ont
des classements différents. Si, toutefois, vous utilisez le mot-clé COLLATE pour créer
explicitement une expression qui les autorise à être compatibles, comme indiqué dans
l'exemple suivant, la requête aboutit :
SELECT *
FROM TestTab
WHERE GreekCol = LatinCol COLLATE greek_ci_as
Bien que LatinCol ait généralement un classement sensible à la casse, le classement insensible
à la casse de l'expression remplace la sensibilité à la casse et permet au A majuscule et A
minuscule d'être traités de la même façon.
La sensibilité au classement d'une fonction dépend du type de données des entrées. Les
fonctions CAST, CONVERT et COLLATE sont sensibles au classement pour les types de
données char, varchar et text. Si les entrées et sorties des fonctions CAST et CONVERT
sont des chaînes de caractères, la chaîne de sortie a l'étiquette de classement de la chaîne
d'entrée. Si l'entrée n'est pas une chaîne de caractères, la chaîne de sortie est Coercibledefault. Dans ce cas, elle reçoit le classement de la base de données actuelle pour la
connexion ou de la base de données qui contient la fonction définie par l'utilisateur, la
procédure enregistrée ou le déclencheur dans lequel CAST ou CONVERT est référencé.
Pour les fonctions prédéfinies qui renvoient une chaîne mais ne prennent pas une entrée de
chaîne, la chaîne de résultat est Coercible-default et reçoit soit le classement de la base de
données actuelle soit le classement de la base de données qui contient la fonction définie par
l'utilisateur, la procédure enregistrée ou le déclencheur dans lequel la fonction est référencée.
Restrictions du mot-clé COLLATE
Le mot-clé COLLATE et les fonctionnalités qui lui sont associées sont puissants et offrent
une grande flexibilité au développeur de bases de données internationales. Il existe, toutefois,
des restrictions. Ces restrictions et leurs solutions respectives sont répertoriées dans cette
section.
Renvoyer moins d'une liste complète de classements
La fonction fn_helpcollations renvoie une liste de tous les classements fournis par
SQL Server. Les exceptions sont représentées par trois classements qui sont désapprouvés et
ne s'affichent pas dans ::fn_helpcollations(). Le classement hindi est désapprouvé dans
SQL Server 2005 parce que la table de tri de Windows 2000 Bêta 2 est utilisée dans cette
version de SQL Server. Le classement existe toujours dans le serveur, mais il ne sera pas pris
en charge dans une future version SQL Server. Les classements Hindi et Lithuanian_Classic
sont désapprouvés dans SQL Server 2005. Ces classements existent toujours dans le serveur,
mais ils ne seront pas pris en charge dans une version future de SQL Server.
Si vous souhaitez travailler par programmation avec les classements, vous devez fournir une
interface utilisateur pour cette fonctionnalité vous-même.
Conversion implicite
La conversion implicite de données de caractères non Unicode entre les classements est non
déterministe. La conversion implicite de données de caractères non Unicode entre les
classements est également considérée comme non déterministe, à moins que le niveau de
compatibilité soit déterminé à 80 ou moins.
Dans les versions précédentes de SQL Server, les noms d'objets de système et de types de
système étaient comparés au classement de la base de données principale. Dans
SQL Server 2005, les noms d'objets de système et de types de système sont convertis
automatiquement de sorte à correspondre au classement de la base de données actuelle. Si les
références à ces objets de votre script ou de vos applications ne correspondent pas à leur
affichage dans le catalogue et que le classement de la base de données actuelle provoque une
incohérence, le script ou l'application risque d'échouer. Par exemple, l'instruction EXEC
SP_heLP échoue si la base de données actuelle a un classement sensible à la casse.
Problèmes liés à la définition de classement au niveau des colonnes
Une base de données peut parfois nécessiter un ordre de tri (par exemple, Latin1_General)
tandis que les colonnes individuelles ont besoin d'un autre (par exemple, Greek). De même, la
base de données peut parfois contenir des données multilingues qui doivent être triées suivant
plus d'un classement. Dans ce cas, vous ne pouvez pas définir un seul classement. Dans les
deux cas, si vous avez la possibilité de définir plusieurs classements, et que chacun d'eux peut
être indexé, vous pouvez accéder aux données de chaque langue cible en spécifiant le
classement correct. Par exemple, vous pouvez afficher plus facilement les données grecques
en spécifiant le classement Greek.
En outre, en spécifiant le classement supplémentaire, vous pouvez utiliser la recherche
indexée dans les requêtes concernant ces données. La possibilité d'indexer la colonne pour la
recherche est une condition critique. Dans l'exemple du paragraphe précédent, l'utilisation
d'une expression COLLATE dans la clause ORDER BY d'une requête fournit la
fonctionnalité nécessaire pour trier les données ; toutefois, le tri ne sera pas indexé et les
résultats de la requête seront donc renvoyés plus lentement dans de gros datasets. Pour cette
raison, le classement au niveau des colonnes n'est intéressant que si vous n'avez pas de
données unilingues dans une colonne ou si vous dénormalisez votre base de données pour
enregistrer différentes langues dans différentes colonnes.
Classements et tempdb
La base de données tempdb est générée à chaque fois que SQL Server est lancé ; tempdb a
toujours le même classement par défaut que la base de données model. Ce classement est
généralement identique au classement par défaut de l'instance. Si vous créez une base de
données d'utilisateur et spécifiez un classement par défaut autre que model, cette base de
données a un classement par défaut autre que tempdb. Toutes les procédures enregistrées
temporaires et toutes les tables temporaires sont créées et enregistrées dans tempdb. Ceci
signifie que toutes les colonnes implicites des tables temporaires et les constantes, variables et
paramètres Coercible-default des procédures enregistrées temporaires ont des classements
différents de ceux d'objets similaires créés dans les tables permanentes et les procédures
enregistrées.
Ceci risque de causer des problèmes d'incohérence dans les classements entre les bases de
données définies par l'utilisateur et les objets de bases de données système. Par exemple,
supposons qu'une instance de SQL Server 2005 utilise le classement Latin1_General_CS_AS
et que vous exécutiez les instructions suivantes :
CREATE DATABASE TestDB COLLATE Estonian_CS_AS;
USE TestDB;
CREATE TABLE TestPermTable (PrimaryKey int PRIMARY KEY, Col1 nchar );
INSERT TestPermTable VALUES (1, 'a')
Ensuite, créez une table temporaire avec les mêmes déclarations de colonnes que
TestPermTab en utilisant les instructions suivantes :
CREATE TABLE #TestTempTable (PrimaryKey int PRIMARY KEY, Col1 nchar )
INSERT #TestTempTable
SELECT * FROM TestPermTable
GO
Dans ce système, la base de données tempdb utilise le classement
SQL_Latin1_General_CP1_CI_AS (page de code 1252) tandis que TestDB et
TestPermTable.Col1 utilisent le classement Estonian_CS_AS collation (page de code 1257).
Ensuite, vous effectuez une requête pour les lignes qui doivent être identiques à l'aide des
instructions suivantes :
SELECT * FROM TestPermTable t1
JOIN #TestTempTable t2
ON t1.Col1 = t2.Col1
Étant donné que tempdb utilise le classement de serveur par défaut et que
TestPermTable.Col1 utilise un classement différent, SQL Server renvoie cette erreur :
"Msg 468, Level 16, State 9, Line 1
Cannot resolve the collation conflict between
"SQL_Latin1_General_CP1_CI_AS" and "Estonian_CS_AS" in the equal to
operation."
Pour éviter l'erreur, vous pouvez appliquer l'une des solutions suivantes :


Spécifiez que la colonne de la table temporaire utilise le classement par défaut de la
base de données d'utilisateur et non pas tempdb. Votre table temporaire peut ainsi
fonctionner avec les tables de même format dans plusieurs bases de données, si cela
est exigé de votre système.
Spécifiez explicitement le bon classement pour la colonne #TestTempTable. Vous
pouvez effectuer cette opération en utilisant le mot-clé COLLATE dans la définition
de la colonne.
LCID et classements
Windows utilise la référence géographique (LCID) pour définir les ordres de tri. Si vous ne
connaissez pas le LCID, vous pouvez utiliser le LCID par défaut en indiquant 1024 ou
formater vos données en utilisant les fonctions de formatage de Microsoft .NET. Dans une
application ASP Web, vous pouvez utiliser la fonction SetLocale de Microsoft Visual
Basic Scripting Edition (VBScript) pour utiliser les préférences de formatage des date/heure,
des chiffres et de la devise de n'importe quelle région. Toutefois, vu qu'il n'existe pas de
mappage direct entre le LCID et les classements, vous ne pouvez pas déterminer le bon
classement à partir d'un LCID.
Ceci n'est pas très pratique si vous souhaitez pouvoir attribuer automatiquement le meilleur
ordre de tri aux utilisateurs en fonction de leurs paramètres régionaux. Par exemple, si vous
avez un site Web multilingue visité par des personnes de différents pays souhaitant consulter
les informations sur les produits, vous pouvez choisir de mapper les variables
HTTP_ACCEPT_LANGUAGE fournies par leurs navigateurs aux LCID pour formater la
date et la devise en utilisant la propriété Session.LCID. Pour des raisons d'utilisabilité, vous
pouvez également décider d'implémenter le tri en utilisant leurs paramètres régionaux.
Pour générer votre propre fonction de mappage et contourner ce problème, vous pouvez
utiliser la liste d'indicateurs de classement proposée dans le programme d'installation. Un
indicateur de classement fournit un mappage entre un classement spécifique et un classement
standard. Pour obtenir une liste de paramètres régionaux du système et les classements par
défaut recommandés, consultez la section Paramètres des classements dans le programme
d'installation dans la documentation en ligne de SQL Server 2005.
Voici des exemples de classements standard utilisés pour le mappage :




Latin1_General peut être utilisé pour le jeu de caractères anglais américain (page de
code 1252).
Modern_Spanish peut être utilisé pour toutes les variations de l'espagnol qui utilisent
le même jeu de caractères que l'anglais américain (page de code 1252).
L'arabe peut être utilisé pour toutes les variations de l'arabe qui utilisent le jeu de
caractères arabe (page de code 1256).
Japanese_Unicode peut être utilisé pour la version Unicode du japonais dont l'ordre de
tri est différent de celui du japonais mais dont la page de code est la même (932).
Vous pouvez également spécifier l'ordre de tri à utiliser avec l'indicateur de classement que
vous avez sélectionné. L'ordre de tri binaire est l'ordre de tri le plus rapide. Il est sensible à la
casse. Si un ordre de tri binaire est sélectionné, vous ne pouvez pas utiliser les options
sensibles à la casse, aux accents, au kana et à la largeur.
Chaînes ISO et classements
Dans VBScript, vous pouvez obtenir la variable HTTP_ACCEPT_LANGUAGE avec un
script tel que :
Dim stLang
stLang = Request.ServerVariables("HTTP_ACCEPT_LANGUAGE")
Étant donné que beaucoup de développeurs Web utilisent cette valeur comme information sur
les paramètres régionaux, la fonction SetLocale de VBScript a été conçue de sorte à accepter
directement cette valeur en même temps que les valeurs de LCID. Ceci signifie que vous
n'avez pas à suivre l'étape intermédiaire consistant à mapper la valeur à un LCID. Pour chaque
chaîne représentant une région, telle que « en-us » (anglais États-Unis) ou « vi » (vietnamien),
vous devez mapper au classement approprié, Latin1_General ou un classement vietnamien par
exemple.
Classements personnalisés
Les développeurs souhaitent souvent définir leurs propres classements. Cependant, vu que
tous les nouveaux classements de SQL Server sont dérivés des classements de Windows, il
n'est pas possible de créer de nouveaux classements.
De plus, un classement doit être conçu de sorte à définir la méthode de tri de chaque caractère
défini dans la norme Unicode, et il n'existe pas d'interface utilisateur pour créer de nouveaux
classements.
Classement et caractères supplémentaires
Vous ne pouvez utiliser des caractères supplémentaires dans les opérations de tri et de
comparaison que si vous utilisez un des classements _90. Ces comparaisons sont seulement
basées sur les points de code et non pas sur d'autres méthodes pertinentes du point de vue
linguistique. Faites attention lorsque vous utilisez des caractères supplémentaires dans les
opérations telles que ORDER BY, GROUP BY et DISTINCT, surtout lorsque les caractères
supplémentaires et non supplémentaires sont inclus dans la même opération.
Étant donné que les caractères supplémentaires sont enregistrés sous forme de paires de deux
caractères Unicode codés sur deux octets, la fonction LEN () renvoie la valeur 2 pour chaque
caractère supplémentaire qui est contenu dans la chaîne d'argument. De même, les fonctions
CHARINDEX et PATINDEX ne représentent pas correctement l'occurrence de caractères
supplémentaires à l'intérieur des chaînes de caractères, et la fonction NCHAR renvoie un
caractère qui représente seulement la moitié de la paire de caractères supplémentaires. La
conversion d'une valeur de type binary ou varbinary à un caractère supplémentaire ne
produit également que la moitié d'une paire de caractères supplémentaires.
Les fonctions LEFT, RIGHT, SUBSTRING, STUFF et REVERSE peuvent séparer des paires
de caractères supplémentaires et conduire à des résultats imprévus.
Dans SQL Server 2005, il est possible de contourner les restrictions des fonctions du système
lorsque vous utilisez des caractères supplémentaires à l'aide de fonctions CLR définies par
l'utilisateur. Pour plus d'informations sur la manière de créer et utiliser des fonctions gérant
les caractères supplémentaires à l'aide de code géré dans le CLR .NET Framework, consultez
les exemples fournis avec SQL Server 2005. L'un de ces exemples, l'exemple
StringManipulate, démontre le traitement des chaînes de caractères supplémentaires et
l'implémentation des fonctions de chaîne LEN(), LEFT(), RIGHT(), SUBSTRING() and
REPLACE(), mais avec une fonctionnalité de reconnaissance des caractère supplémentaires
permettant de gérer les chaînes de caractères supplémentaires et Unicode. L'exemple inclut
des scripts en C# ou Visual Basic .NET, ainsi qu'un script Transact-SQL pour le chargement
de l'assembly et la création des fonctions dans SQL Server. Pour plus d'informations sur les
exemples disponibles, consultez la section Création de fonctions CLR dans la documentation
en ligne de SQL Server 2005.
Communications serveur-client (Technologies d'accès aux
données)
Dans les applications de base de données, l'utilisation d'outils SQL Server tels que
SQL Server Management Studio ne suffit pas. En général, le serveur interagit avec les autres
serveurs ou les clients, en utilisant une ou plusieurs des normes d'accès aux données. Dans ce
contexte, l'application ou la couche qui se connecte à SQL Server est le client. Dans ce
document, il existe deux types de clients :


Clients Unicode : SQL Native Client, OLE DB et ODBC versions 3.7 et ultérieures
(MDAC 2.8 et versions ultérieures)
Clients non Unicode : ODBC version 3.7 et versions antérieures et DB-Library
(MDAC 2.xx)
Cette section présente les technologies d'accès aux données qui sont disponibles et aborde
brièvement les problèmes que vous risquez de rencontrer lorsque vous travaillez avec des
données multilingues dans un environnement client-serveur.
DB-Library
Bien que le moteur de base de données de SQL Server 2005 prenne toujours en charge les
connexions des applications existantes qui utilisent les API DB-Library et Embedded SQL, il
n'inclut pas les fichiers ou la documentation nécessaires pour effectuer un travail de
programmation sur les applications qui utilisent ces API. Une version future du moteur de
base de données de SQL Server n'inclura pas la prise en charge des connexions à partir des
applications DB-Library ou Embedded SQL. En outre, il n'existe pas de version Unicode de
DB-Library.
N'utilisez donc pas DB-Library pour développer de nouvelles applications. En outre,
supprimez toute dépendance envers DB-Library en modifiant des applications existantes. Au
lieu de ces API, utilisez l'espace de noms SQLClient ou une API telle que OLE DB ou
ODBC.
SQL Server 2005 n'inclut pas la DLL DB-Library nécessaire pour exécuter ces applications.
Pour exécuter des applications DB-Library ou Embedded SQL, vous devez avoir la DLL DBLibrary de SQL Server 6.5, SQL Server 7.0 ou SQL Server 2000 à votre disposition.
SQL-DMO
SQL-DMO (SQL Distributed Management Objects) est une couche COM qui encapsule la
base de données SQL Server et la gestion des réplications. Dans la mesure où il s'agit d'une
couche COM, les règles qui sont appliquées à ADO et OLE DB s'appliquent également à
SQL-DMO. SQL-DMO a également des propriétés qui peuvent être utilisées pour les
fonctionnalités mentionnées précédemment, telles que la propriété Collation sur les objets
SQLServer2, Database2, Column2, SystemDateType2 et UserDefinedDataType2.
OLE DB
OLE DB est le composant central de MDAC (Microsoft Data-Access Components). OLE DB
est basé sur COM, et toutes les chaînes sont donc des BSTR Unicode (UTF-16 dans
Windows XP, Windows Server 2003 et Windows 2000 ; UCS-2 dans tous les autres systèmes
d'exploitation). Cependant, les versions de MDAC antérieures à MDAC 2.8 SP1 ne prennent
pas en charge les instances nommées. Il est possible que les applications ne puissent pas se
connecter aux instances nommées de SQL Server 2005. Pour tirer parti des fonctionnalités de
SQL Server 2005, effectuez une mise à niveau vers MDAC 2.8 SP1.
Version
SQL Server 7.0
SQL Server 2000
SQL Server 2005
Data-Access Library
MDAC version 2.1
MDAC version 2.6
MDAC version 2.8
Pour SQL Server, le fournisseur est le fournisseur Microsoft OLE DB pour SQL Server
(SQLOLEDB). Les données sont converties à Unicode le cas échéant, à l'aide du classement
des données réelles.
ADO
Les objets de données Microsoft ActiveX® (ADO) constituent une interface Visual Basic et
de script conviviale qui agit comme un wrapper autour d'OLE DB. Il s'agit également d'un
composant COM, qui prend donc en charge Unicode. Il est impossible de découpler ADO et
OLE DB de façon à permettre les conversions entre les deux ; s'il existe des problèmes, ils
concernent par conséquent toujours la couche OLE DB.
ODBC
Certaines versions d'ODBC prennent en charge Unicode. Un problème important concernant
les données non Unicode réside dans la façon dont les données sont traduites entre les pages
de code ou depuis et vers Unicode lorsque ODBC est utilisé. Lorsque vous utilisez une
version d'ODBC antérieure à 3.7, les données sont converties d'Unicode à ANSI à l'aide de la
page de code système par défaut. Même si vous installiez une version d'ODBC ultérieure,
Jet 3.5 effectuerait la même conversion.
Il existe deux paramètres possibles de l'attribut SQL_COPT_SS_TRANSLATE lorsqu'il est
envoyé à SQLSetConnectAttr :

SQL_XL_OFF
Le pilote ne traduit pas les caractères d'une page de code vers une autre en données de
caractères échangées entre le client et le serveur.

SQL_XL_ON
Le pilote traduit les caractères d'une page de code vers une autre en données de
caractères échangées entre le client et le serveur. Le pilote configure automatiquement
la traduction des caractères, en déterminant la page de code installée sur le serveur et
utilisée par le client.
Par défaut, c'est l'attribut SQL_XL_ON qui est utilisé. Vous pouvez également le définir en
utilisant la méthode SQL-DMO TranslateChar de l'objet SQLServer. Généralement, ce
paramètre par défaut fournit le comportement souhaité (l'activation d'auto_translate) chaque
fois que vous traitez des données non Unicode.
Si vous décidez de désactiver auto-translate, vous devez en comprendre les conséquences. Les
développeurs désactivent souvent auto-translate car ils supposent que ceci permettra au client
et au serveur de communiquer sans avoir à faire correspondre les pages de code. Toutefois,
cette interaction n'est pas prise en charge. En outre, avant de trier et d'analyser les données
non Unicode définies avec un classement Windows, SQL Server convertit d'abord les données
à Unicode. Ainsi, si auto-translate est désactivé, les données Unicode traduites risquent de ne
pas être correctement traduites vers leur page de code non Unicode originale lorsqu'elles sont
récupérées par le côté client.
Microsoft SQL Native Client
Microsoft SQL Native Client (précédemment connu sous le nom de SQL Native Client) a été
conçu pour proposer une méthode d'accès simplifiée aux données natives de SQL Server à
l'aide d'OLE DB ou ODBC. Il combine les technologies OLE DB et ODBC dans une
bibliothèque et propose une manière d'innover et de créer de nouvelles fonctionnalités d'accès
aux données sans changer les composants MDAC actuels qui font maintenant partie de la
plate-forme Microsoft Windows.
Si vous ne souhaitez pas utiliser les nouvelles fonctionnalités de SQL Server 2005, vous
n'avez pas besoin d'utiliser le fournisseur OLE DB de SQL Native Client ; vous pouvez
continuer à utiliser votre fournisseur d'accès aux données actuel, en général SQLOLEDB. Si
vous améliorez une application existante et souhaitez utiliser les nouvelles fonctionnalités de
SQL Server 2005, utilisez le fournisseur OLE DB de SQL Native Client.
SQL Native Client utilise des composants dans MDAC, mais n'est pas explicitement
dépendant d'une version particulière de MDAC.
Pour les nouvelles applications, si vous utilisez un langage de programmation géré tel que
Microsoft Visual C#.NET ou Visual Basic.NET et que vous avez besoin d'accéder aux
nouvelles fonctionnalités de SQL Server 2005, utilisez le fournisseur de données
.NET Framework pour SQL Server qui fait partie de .NET Framework pour
Visual Studio 2005. Celui-ci constitue le composant d'accès aux données le plus robuste pour
SQL Server 2005.
Si vous développez une application COM et que vous avez besoin d'accéder aux nouvelles
fonctionnalités de SQL Server 2005, utilisez SQL Native Client. SQL Native Client prend en
charge l'accès aux bases de données SQL Server précédentes en commençant par
SQL Server 7.0 et les versions plus récentes.
Pour les applications OLE DB et ODBC, la question principale est de savoir si vous avez
besoin d'accéder aux nouvelles fonctionnalités de SQL Server 2005. Si vous disposez d'une
application mûre qui n'a pas besoin des nouvelles fonctionnalités de SQL Server 2005, vous
pouvez continuer à utiliser MDAC. Toutefois, les valeurs renvoyées des type de données
varchar(max), nvarchar(max), varbinary(max), xml, UDT ou d'autres types d'objets
similaires ne peuvent pas être renvoyées aux versions client antérieures à SQL Server 2005. Si
vous souhaitez utiliser ces types comme valeurs renvoyées, vous devez utiliser
SQL Native Client.
MDAC et SQL Native Client fournissent tous deux un accès de données natif aux bases de
données SQL Server, mais SQL Native Client a été surtout conçu pour exposer les nouvelles
fonctionnalités de SQL Server 2005 tout en maintenant la compatibilité ascendante avec les
versions précédentes. En outre, bien que MDAC contienne des composants permettant
d'utiliser OLE DB, ODBC et ADO (ActiveX Data Objects), SQL Native Client implémente
seulement OLE DB et ODBC.
Pour plus d'informations sur la différence entre SQL Native Client et MDAC, consultez la
section Mise à jour d'une application vers SSQL Native Client à partir de MDAC dans la
documentation en ligne de SQL Server 2005.
Pour tirer parti des nouvelles fonctionnalités introduites dans SQL Server 2005, les
applications existantes qui utilisent les objets ADO (ActiveX Data Objects) doivent utiliser le
fournisseur OLE DB de SQL Native Client comme fournisseur d'accès aux données.
Configurations de serveur et client Unicode et non Unicode
Cette section examine les problèmes à prendre en considération lorsque vous utilisez des
systèmes hérités qui ne sont pas entièrement compatibles avec Unicode.
Serveur Unicode et client Unicode
Il s'agit de la configuration idéale. En gardant les données en Unicode durant tout le
processus, vous pouvez garantir les meilleures performances et protéger également les
données récupérées de l'altération. C'est le cas avec ADO et OLE DB ou avec SQL Server
Native Client.
Serveur Unicode et un ou plusieurs clients non Unicode
Dans ce type de configuration, vous n'aurez probablement aucun problème à stocker les
données, mais il y existe une restriction sérieuse lorsqu'il s'agit d'afficher les données sur le
client et de les utiliser. À un moment donné, la page de code client doit être utilisée pour
convertir les données Unicode.
Par exemple, une connexion à une base de données SQL Server 2005 à partir d'un ordinateur
utilisant DB-Library correspond à ce scénario. DB-Library est une interface qui autorise les
applications C à accéder à SQL Server. DB-Library n'a pas été considérablement mis à niveau
depuis SQL Server 6.5. Il est donc soumis aux mêmes restrictions que SQL Server 6.5 : Les
données peuvent uniquement être basées sur une page de code, la page de code de l'OEM par
défaut du système. Vous pouvez également choisir si les informations sur les paramètres
régionaux seront basées sur les paramètres du système client ou pas.
SQL Server Client Network Utility fournit deux options non-exclusives sur la manière dont
DB-Library convertit les informations : conversion ANSI à OEM automatique et utilisation de
paramètres internationaux. Ces deux options sont sélectionnées par défaut.
Comme il n'est pas possible de gérer les données d'autres pages de code, DB-Library doit
uniquement être utilisé avec les systèmes hérités qui manipulent un sous-ensemble de données
à partir de SQL Server. Cette technologie est uniquement fournie pour la compatibilité
ascendante, mais demeure une possibilité pour la prise en charge de données multilingues
dans les applications héritées.
D'autres clients non compatibles Unicode incluent les versions précédentes de Microsoft
Office. Si vous vous connectez à une base de données SQL Server en utilisant une ancienne
version d'Office Access, les caractères Unicode peuvent être convertis en points
d'interrogation, comme sur la figure 9.
Figure 9. Noms de table japonais, affichés sous forme de points d'interrogation.
Ceci est dû au fait que le comportement par défaut dans ODBC 3.7 consistait à effectuer
automatiquement la conversion vers la page de code système. Cependant, comme les
caractères japonais n'ont pas été inclus dans la page de code de l'ordinateur client anglaisÉtats-Unis (1252), ils sont remplacés par des points d'interrogation.
Qui plus est, il n'est pas possible de se connecter à ces tables. Toute tentative de connexion
renverra un message d'erreur. Jet et ODBC essaient de se connecter à une table nommée
dbo.????, ce qui échouera car aucune table de ce nom n'existe. Cette erreur se produira avec
toutes les données ne figurant pas dans la page de code du système client.
Une fois les données converties dans la mauvaise page de code et remplacées par des points
d'interrogation, il n'est plus possible de les reconvertir vers leur valeur d'origine. Par exemple,
si vous utilisez un client non-Unicode pour la connexion à une table contenant des données
coréennes en caractères Unicode, des points d'interrogation remplacent les caractères de texte
coréens, comme illustré à la figure 10.
Figure 10. Exemple de caractères ne pouvant pas être affichés dans une base de données
cliente non-Unicode.
Les trois clients hérités (DB-Library, ODBC et Jet 3.5) ont en commun l'incapacité à prendre
en charge les caractères Unicode, sauf si ces caractères peuvent être convertis vers la page de
code système par défaut. Évitez d'utiliser ces composants pour le développement de clients,
sauf si vous savez que les données peuvent être incluses dans la page de code système par
défaut. Pour plus d'informations, consultez la section Gestion de la conversion des données
entre un serveur Unicode et un client non Unicode dans la documentation SQL Server 2005
en ligne.
En outre, puisque COM fournit des points d'entrée pour l'accès aux données SQL Server dans
Office Access, les paramètres régionaux du client sont utilisés pour interpréter la signification
des données. Ceci peut affecter l'entrée des valeurs de date/heure, de nombres et de devises.
Pour plus d'informations sur ce problème, consultez la section « Gestion des problèmes de
paramètres régionaux » plus loin dans ce document.
Si vous utilisez une interface frontale Office Access pour l'accès à SQL Server, nous vous
recommandons d'effectuer la mise à jour de celle-ci pour profiter des nouvelles
fonctionnalités et de la prise en charge d'Unicode de Microsoft Office 2003 Access ou de
Microsoft Office System 2007 Access. L'aide en ligne d'Office Access fournit des conseils
pour la mise à niveau des applications Office existantes. Notez que le format ADP a été
abandonné après Microsoft Office Access 2000.
Pour plus d'informations sur l'optimisation de votre application Office Access pour
l'amélioration de ses performances et de ses capacités à être mise à jour, consultez le livre
blanc Optimisation des applications Microsoft Office Access liées à SQL Server dans MSDN
Library.
Serveur non Unicode et client Unicode
Il s'agit d'une configuration défavorable pour les données multilingues, car vous ne pourrez
pas enregistrer de données sur le serveur. Dans la mesure où SQL Server 2000 et
SQL Server 2005 sont compatibles Unicode, il est peu probable que vous rencontrerez cette
configuration, à moins qu'un serveur lié à une base de données SQL Server 6.5 soit défini.
Vous pourrez recevoir des données valides de l'instance de SQL Server 6.5, mais ne pourrez
pas insérer de données qui ne sont pas incluses dans la page de code par défaut du serveur.
Conversion de données multilingues des versions précédentes de SQL Server
Certaines applications héritées, qui peuvent avoir été créées avant que la prise en charge
complète d'Unicode ait été implémentée dans SQL Server, utilisent des schémas de codage
personnalisés pour la gestion des données multilingues. Pour préserver les données, vous
pouvez utiliser le programme de copie en bloc ('utilitaire bcp) pour enregistrer les données
sous forme binaire et empêcher ainsi toute erreur de conversion. Ensuite, utilisez l'utilitaire
pour réimporter les données à l'aide de la page de code appropriée avec le paramètre de ligne
de commande -C. Pour plus d'informations sur l'utilitaire bcp, consultez la section Utilisation
d'utilitaires de ligne de commande avec les données multilingues de ce document.
Données multilingues dans l'interface utilisateur
Les outils d'administration et de gestion de SQL Server ont été mis à jour pour améliorer la
prise en charge des données multilingues. Cette section décrit certaines modifications que
vous constaterez dans SQL Server 2005.
Modification générales de l'interface utilisateur
La nouvelle interface de SQL Server Management Studio offre la flexibilité nécessaire pour
l'hébergement d'une variété d'éditeurs de texte et de requêtes, de boîtes de dialogue
d'administration, d'Assistants, de concepteurs et d'explorateurs dans un shell commun. Au
sein de ce shell, vous pouvez spécifier la langue de session et contrôler l'affichage des
éléments suivants :





la langue qui sera utilisée pour les messages d'erreur et autres messages système ;
le format des données de date et d'heure ;
les noms des jours et des mois, y compris leurs abréviations ;
le premier jour de la semaine ;
les symboles et les formats des devises.
Pour modifier la police utilisée dans SQL Server Management Studio, dans le menu Outils,
sélectionnez Options, pointez sur Environnement et sélectionnez ensuite la page Polices et
couleurs pour personnaliser les paramètres de style, taille et couleur d'affichage des fenêtres
d'outils individuelles qui ont des volets d'affichage dans SQL Server Management Studio. Si
vous modifiez le texte, les modifications ne prennent pas effet pendant la session durant
laquelle vous les effectuez. Cependant, vous pouvez évaluer les effets de la modification en
ouvrant une autre instance de SQL Server Management Studio.
34 langues sont disponibles dans les paramètres de session. Pour obtenir la liste des langues,
consultez sys.syslanguages (Transact-SQL) dans la documentation en ligne de
SQL Server 2005.
Vous pouvez également modifier les options de texte et d'affichage pour l'utilisation des
objets multidimensionnels et de data-mining des packages Integration Services ou d'Analysis
Services à l'aide de Business Intelligence Development Studio. Utilisez les pages
Environnement de la boîte de dialogue Options pour configurer des options comprenant la
langue utilisée dans l'environnement pour l'interface utilisateur et l'aide en ligne, les polices et
la configuration du clavier. Après avoir configuré l'environnement de développement à votre
gré, vos configurations sont enregistrées dans un fichier *.suo réutilisable dans le dossier de la
solution.
Remarque : Pour afficher des caractères supplémentaires, vous devez installer une police
qui prend en charge les extensions correspondant à ces caractères. Pour plus d'informations,
consultez l'article Caractères supplémentaires et de substitution dans la bibliothèque MSDN.
Pour afficher la liste des langues disponibles pour l'indexation de texte intégral et les
opérations de requêtes, utilisez sys.fulltext_languages. Cette vue de catalogue contient une
ligne par langue. Chaque ligne fournit une représentation sans ambiguïté des ressources
linguistiques de texte intégral qui sont enregistrées avec Microsoft SQL Server. Le nom ou le
LCID peuvent être spécifiés dans les requêtes de texte intégral et dans le langage de définition
des données d'index de texte intégral.





Pour définir la langue de session côté serveur, utilisez SET LANGUAGE.
La langue de session peut également être définie côté client en utilisant OLE DB,
ODBC ou ADO.NET.
Pour OLE DB, utilisez la propriété SSPROP_INIT_CURRENTLANGUAGE.
Pour ODBC, utiliser le mot-clé LANGUAGE. Pour plus d'informations, consultez
l'article SQLConfigDataSource dans la bibliothèque MSDN.
Pour ADO.NET, utilisez le paramètre Current Language de l'objet
ConnectionString.
Prise en charge des scripts complexes
SQL Server 2005 prend en charge l'entrée, le stockage, la modification et l'affichage de scripts
complexes dans l'intégralité du moteur et des outils de la base de données. Les scripts
complexes incluent les scripts bidirectionnels, tels que l'arabe, les scripts dont les caractères
changent de forme en fonction de leur position, tels que l'indien et le thaï, et les langues qui
nécessitent des dictionnaires internes pour reconnaître des mots car ceux-ci ne disposent
d'aucun séparateur, tels que le thaï.
Les applications de base de données qui interagissent avec SQL Server doivent utiliser des
contrôles qui prennent en charge les scripts complexes. Les contrôles standard de Windows
Forms qui sont créés dans le code géré sont compatibles avec les scripts complexes.
Cependant, les fichiers requis pour la prise en charge des scripts complexes doivent être
installés sur votre ordinateur via les Options régionales et linguistiques. Pour plus
d'informations, consultez la section Prise en charge des scripts complexes dans la
documentation en ligne de SQL Server 2005.
Mise en forme dans le Concepteur de requêtes
Dans le Concepteur de requêtes, vous pouvez pour l'essentiel entrer des informations dans le
volet Grille correspondant aux paramètres régionaux par défaut de l'ordinateur ou utiliser
explicitement la fonction CONVERT pour forcer le traitement d'une chaîne d'un format
spécifique.
L'utilisation des paramètres régionaux fait l'objet de certaines restrictions à prendre en
compte :



Les formats de données longs ne sont pas pris en charge.
Les symboles de devises ne doivent pas être entrés dans le volet Grille, bien que le
symbole du dollar ($) puisse éventuellement être utilisé. Quel que soit votre choix, le
symbole de devise récupéré à partir des paramètres régionaux sera utilisé dans le volet
Résultats.
Le signe moins des nombres négatifs sera toujours situé à gauche, sans parenthèses,
quels que soient les paramètres régionaux. Ainsi, -1 devra être représenté par -1 et non
1-, (1) ou toute autre variante valide pouvant avoir été spécifiée dans la boîte de
dialogue Options régionales.
Ces restrictions sont nécessaires pour permettre un certain taux de prise en charge globale
dans le Concepteur de requêtes, mais ne bloqueront pas la plupart des efforts d'utilisation de
données spécifiques à des paramètres régionaux.
Dans la mesure où toutes les informations entrées dans le volet Grille seront traduites dans un
format indépendant des paramètres régionaux dans le volet SQL, sur un ordinateur allemand
Standard, « 03.09.65 » sera traduit par { ts ' 1965-09-03 00:00:00 }. Toutes les données
entrées directement dans le volet SQL doivent avoir ce format ou, si ce n'est pas le cas,
inclure un appel explicite à CONVERT.
Ordre de tri
Le tri des données affichées dans le volet Résultats n'est pas influencé par les paramètres
régionaux. Ce sont les règles de classement qui régissent l'interprétation de l'instruction
ORDER BY.
Transact-SQL multilingue
Lorsque vous envoyez une instruction SQL contenant des données multilingues au serveur,
deux problèmes affectent l'acheminement correct des données vers le serveur : (1) le codage
de l'instruction SQL et (2) le codage des littéraux de chaîne de l'instruction.
Codage des instructions SQL
Il existe des restrictions s'appliquant aux caractères pouvant être utilisés dans les instructions
Transact-SQL. Vous pouvez entrer des caractères DBCS pour les littéraux et les noms d'objets
de base de données, les alias, les noms de paramètres et les indicateurs de paramètres.
Cependant, vous ne pouvez pas utiliser de caractères DBCS pour les éléments du langage
SQL tels que les noms de fonction ou les mots-clés. Ainsi, lorsque vous tapez des mots-clés
SQL tels que SELECT, vous devez utiliser les caractères demi-chasse « SELECT » au lieu
des caractères japonais pleine chasse « ‚r‚d‚k‚d‚b‚s ».
Si la chaîne SQL utilise Unicode (comme par exemple toute chaîne SQL utilisant ADO), vous
pouvez coder tout type de caractère. Si la chaîne n'utilise pas Unicode (comme par exemple,
une chaîne d'un fichier de commandes ou .sql non Unicode), la conversion doit être effectuée
à un moment ou un autre. Lorsque vous effectuez cette conversion, vous devez planifier
soigneusement cette tâche et prendre en compte la page de code système par défaut de
l'ordinateur sur lequel la conversion est effectuée, pour empêcher tout problème dans les
applications multilingues.
Codage de littéraux de chaîne dans les instructions SQL
Les constantes de chaîne Unicode qui apparaissent dans du code exécuté sur le serveur, telles
que les procédures stockées et les déclencheurs, doivent être précédées de la majuscule N. Si
un littéral de chaîne n'est pas de type Unicode (marqué du préfixe N), la chaîne est convertie
dans la page de code par défaut de la base de données, qui peut ne pas reconnaître certains
caractères. Avec les données multilingues, il est préférable d'utiliser un type de données
Unicode et des littéraux de chaîne Unicode.
L'exemple suivant correspond à une chaîne Unicode conçue en plaçant un préfixe « n »
devant la chaîne :
SELECT n'??????'
La figure 11 illustre comment cette chaîne, qui est le nom de la langue hindi en hindi,
apparaîtrait sur un ordinateur sur laquelle la police hindi correcte est installée.
Figure 11. Exemple de caractères hindi sur un client hindi
Si le préfixe « n » n'avait pas été placé devant la chaîne, elle aurait été convertie en ??????.
Ceci se produit également avec les données qui ont une page de code qui ne correspond aux
valeurs par défaut du système.
Avertissement : Rappelez-vous que l'utilisation du préfixe « n » dans les littéraux de chaîne
comme les types de données (nchar, nvarchar et ntext) pour la représentation des données
Unicode est spécifique à SQL Server. La spécification SQL ANSI-92 définit les types de
données de caractère nationaux mais ne les spécifie pas comme devant être de type Unicode.
La spécification SQL ANSI-99 aborde l'utilisation d'un ensemble de types Unicode avec un
préfixe « u » (par exemple, utext, uchar et uvarchar). Ces types de données ne sont pas
disponibles dans SQL Server.
Utilisez le préfixe N devant les chaînes pour vous assurer qu'elles sont transmises en tant que
chaînes Unicode. Ceci permet d'éviter des problèmes de conversion inopinés lors de
l'utilisation de la page de code système par défaut du serveur.
Si votre application n'envoie pas de données Unicode au serveur SQL Server et que la page de
code ANSI du client correspond à la page de code du serveur SQL Server, il n'est pas
nécessaire de préfixer les constantes de chaîne avec N. Vous n'encourrez aucune perte de
données résultant de l'omission du préfixe.
Si vous utilisez un serveur lié à SQL Server 7.0, des éléments supplémentaires doivent être
pris en compte. SQL Server 7.0 vous permet de sélectionner pendant l'installation un
classement Unicode qui est indépendant de l'ordre de tri, ce qui peut dans certains cas
entraîner des résultats différents entre les opérations concernant des chaînes préfixées avec N
et celles qui n'utilisent aucun préfixe. Pour plus d'informations sur ce problème, consultez le
site Assistance et support produit de Microsoft.
Fonctions de traitement des chaînes
Transact-SQL dispose de fonctions de traitement prédéfinies dont les implications
multilingues doivent être prises en compte :
ASCII
Renvoie le point de code du premier caractère d'une chaîne utilisant la page de code système
par défaut actuelle. Si le caractère ne figure pas dans cette page de code, la valeur 63 est
renvoyée (point de code correspondant à un point d'interrogation). Cette fonction est
semblable à la fonction Asc() de Visual Basic et VBScript.
CHAR
Renvoie un caractère, en fonction du point de code ANSI donné. C'est en gros l'opération
inverse de la fonction ASCII. Elle est semblable à la fonction Chr() de Visual Basic et
VBScript. Si le point de code ne se situe pas dans la plage 0–255, la valeur renvoyée est Null.
NCHAR
Renvoie un caractère en fonction de son point de code Unicode. NCHAR est l'équivalent
Unicode de la fonction CHAR. Celle-ci est semblable à la fonction ChrW() de Visual Basic
et VBScript.
UNICODE
Renvoie le point de code du premier caractère d'une chaîne. UNICODE est l'équivalent
Unicode de la fonction ASCII. Cette fonction est semblable à la fonction AscW() de
Visual Basic et VBScript.
Vous trouverez un exemple de la fonction NCHAR plus haut dans ce document (voir la
section « Types de date/heure : datetime, smalldatetime »), dans lequel elle a été utilisée pour
ajouter la marque RLM (marque de droite à gauche) devant une date hijri. L'ajout de la
marque RLM permet de s'assurer que la date est mise en forme de la manière prévue.
Prise en charge des paramètres régionaux dans
SQL Server 2005
SQL Server 2000 inclut la prise en charge spécifique des paramètres régionaux de 33 langues
différentes. Dans SQL Server 2005, la prise en charge de toutes les langues prises en charge
par le système d'exploitation Microsoft Windows a été ajoutée. L'annexe B contient une liste
de toutes les langues prises en charge, avec leur identificateur de paramètres régionaux.
Vous pouvez obtenir la liste de ces langues et des informations sur celles-ci en utilisant la
procédure stockée sp_helplanguage. Notez que bien que chaque version de SQL Server
stocke les informations complètes concernant de nombreux éléments ci-dessous, vous
n'obtiendrez pas les messages système traduits pour tous les paramètres régionaux, à moins
d'installer une version localisée du produit.
Les informations sur les langues sont enregistrées dans la table syslanguages, à l'exception
des messages, qui sont enregistrés dans sysmessages.
Paramètres de langue
Chaque instance de SQL Server doit avoir une langue par défaut qu'elle utilise pour gérer les
éléments tels que les formats de date et les messages. Ces informations sont enregistrées pour
chaque connexion au serveur qui est créée. Bien que la définition d'une langue par défaut pour
le serveur soit effectuée initialement pendant l'installation, elle peut être remplacée au niveau
du serveur dans l'onglet Avancé de la boîte de dialogue Propriétés de SQL Server, comme
indiqué sur la figure 12. Dans SQL Server 2000, cette option se situe dans l'onglet
Paramètres du serveur).
Figure 12. Définition de la langue par défaut pour le serveur (cliquez sur l'image pour
l'agrandir)
Vous pouvez également utiliser la procédure stockée sp_configure pour modifier la langue
par défaut. Par exemple, l'instruction suivante change la langue en italien :
sp_configure "language", 6
Le paramètre de langue par défaut peut être remplacé à chaque connexion grâce à la
procédure stockée sp_addlogin ou en utilisant la boîte de dialogue Propriétés de la
connexion illustrée à la figure 13.
Figure 13. Définition de la langue par défaut pour une connexion (cliquez sur l'image
pour l'agrandir)
La langue par défaut peut être remplacée au niveau de la session en utilisant l'instruction SET
LANGUAGE, comme dans les exemples suivants :
SET
SET
SET
SET
LANGUAGE
LANGUAGE
LANGUAGE
LANGUAGE
French
èeština
Çѱ¹¾î
N'“ú–{Œê'
Manipulation de chaînes
Des méthodes individuelles d'accès aux données fournissent leurs propres méthodes pour la
spécification d'une langue hors d'un appel à SET LANGUAGE.


ADO prend en charge un mot-clé de langue spécifique au fournisseur dans
ConnectionString.
OLE DB peut définir la propriété SSPROP_INIT_CURRENTLANGUAGE,
spécifique à un fournisseur.


ODBC peut spécifier une langue dans la définition de la source de données ou dans le
mot-clé LANGUAGE de la chaîne de connexion.
DB-Library peut utiliser dblogin pour allouer un LOGINREC, suivi de
DBSETNATLANG pour spécifier un paramètre de langue.
Les paramètres de langue (qu'ils soient spécifiés au niveau du serveur, de la connexion ou de
la session) affectent les éléments suivants :





Messages
Date et heure
le premier jour de la semaine ;
l'unité et le symbole des devises ;
les noms des mois/jours et les noms abrégés des mois.
Messages
SQL Server 2000 et SQL Server 2005 prennent en charge l'utilisation de plusieurs copies
spécifiques à chaque langue des chaînes et des messages d'erreur système. Ces messages sont
enregistrés dans la table sysmessages de la base de données Master. Lorsque vous installez
une version localisée de SQL Server, ces messages système sont traduits pour la version dans
cette langue. Par défaut, cet ensemble de messages est également disponible en anglais (ÉtatsUnis). Utilisez Set Language pour spécifier la langue de la session de serveur. Par défaut, les
messages sont envoyés dans la langue de la version installée.
Lorsque SQL Server envoie un message à une connexion, il utilise le message localisé si
l'identificateur de langue correspond à l'un des identificateurs de langue de la colonne
msglangid de la table sysmessages. Ces identificateurs ont un format décimal et représentent
le code de paramètres régionaux (LCID) du message. S'il n'y a pas de message avec le même
LCID dans la table sysmessages, les messages anglais (États-Unis) sont envoyés.
Vous pouvez ajouter un message défini par l'utilisateur dans une langue spécifique à la table
sysmessages en utilisant le paramètre @lang de la procédure stockée système
sp_addmessage. Le numéro d'erreur doit être supérieur à 50 000 et vous devez spécifier pour
le message le paramètre @lang en tant que langue ou un alias nommé mappant le LCID.
Puisque plusieurs chaînes et messages d'erreur système spécifiques à des langues peuvent être
installés sur le serveur, la valeur langue indique la langue dans laquelle les messages doivent
être écrits dans la table sysmessages. Lorsque langue n'est pas spécifié, la langue est par
défaut celle de la session de serveur. Les définitions de langue prises en charge sont stockées
dans master.dbo.syslanguages.
Si vous devez installer des versions dans plusieurs langues de sysmessages, consultez le site
Assistance et support technique de Microsoft pour les étapes et exigences supplémentaires.
Les installations de versions de langues différentes d'instances de SQL Server sur un même
ordinateur ne sont pas prises en charge. Par exemple, SQL Server 2005 version allemande et
SQL Server 2005 version portugaise (Brésil) ne sont pas pris en charge en tant qu'instances
multiples sur un même ordinateur.
Remarque : De nombreuses tables système des versions précédentes de SQL Server sont
implémentées sous la forme d'un ensemble de vues dans SQL Server 2005. Ces vues portent
le nom de vues de compatibilité et ont pour seul but la compatibilité ascendante. Les vues de
compatibilité exposent les mêmes métadonnées que celles qui étaient disponibles dans
SQL Server 2000. Cependant, elles n'exposent aucune des métadonnées apparentées aux
fonctionnalités introduites dans SQL Server 2005.
Date et heure
Chaque langue possède une valeur par défaut pour le format de date court : mja, jma ou amj.
Vous pouvez remplacer ceci au niveau de la connexion en utilisant le paramètre SET
DATEFORMAT. Pour récupérer la date courte par défaut, utilisez la procédure stockée
sp_helplanguage. La valeur est stockée dans la colonne dateformat.
Premier jour de la semaine
Le premier jour de la semaine varie selon les paramètres régionaux. Dans les 33 langues de la
table syslanguages, il varie entre 1 (lundi) et 7 (dimanche). Ces informations peuvent être
obtenues en utilisant la procédure stockée sp_helplanguage. La valeur est stockée dans la
colonne datefirst.
Unités et symboles des devises
Toute colonne de type money ou smallmoney peut inclure un symbole de devise. Le symbole
ne doit pas obligatoirement être l'un des symboles spécifiés dans la boîte de dialogue Options
régionales et peut être l'un des caractères indiqués dans le tableau suivant.
Symbole de devise
$
£
¤
¥
?
?
ß
?
?
?
£
?
P
?
?
¤
þ
€
Nom de la devise
Valeur Unicode (hexadécimale)
Symbole du dollar (États-Unis) 0024
Symbole de la livre (R.-U.)
00A3
Symbole de devise (Universel) 00A4
Symbole du yen
00A5
Signe de la roupie bengalie
09F2
Symbole de la roupie bengalie 09F3
Symbole du baht thaïlandais 03EF
Symbole du colon
20A1
Symbole du cruzeiro
20A2
Symbole du franc français
20A3
Symbole de la lire
20A4
Symbole du naira
20A6
Symbole de la peseta
20A7
Symbole de la roupie
20A8
Symbole du won
20A9
Symbol du nouveau shekel
20AA
Symbole du dông
20AB
Symbole de l'euro
20AC
Notez que le symbole de l'Euro (valeur hexadécimale 20AC) n'est pas identique à ?, le
symbole de l'ÉCU (valeur hexadécimale 20A0). Si vous tentez d'utiliser ? dans une valeur de
devise, une erreur surviendra.
Noms des mois/jours et noms abrégés des mois
Les noms des mois et des jours se trouvent dans la table syslanguages. Vous pouvez les
récupérer en utilisant la procédure stockée sp_helplanguage, et afficher les colonnes
suivantes :
months
Liste délimitée par des virgules des noms des mois, de janvier à décembre.
shortmonths
Liste délimitée par des virgules des noms abrégés des mois, de janvier à décembre.
days
Liste délimitée par des virgules des jours de la semaine, du lundi au dimanche
Gestion des problèmes de paramètres régionaux avec COM
Bien que SQL Server dispose de fonctionnalités très puissantes en termes de traitement des
valeurs de date/heure et devise, si vous utilisez un service COM tel que ADO pour l'accès
serveur, vous devez tenir compte du fonctionnement de ce service.
Vous pourriez par exemple rencontrer des problèmes si vous souhaitez que Visual Basic
reconnaisse une valeur numérique précédée de l'un des symboles de devise répertoriés dans le
tableau ci-dessus comme étant une valeur de devise. Vous pourriez également rencontrer des
problèmes d'utilisation appropriée par COM des valeurs de date/heure stockées dans les
chaînes.
Pour remédier convenablement à ces problèmes, vous devez comprendre dans le détail ce qui
se passe lorsque votre application convertit une chaîne en une valeur de date/heure ou devise.
Tout d'abord, déterminez si la conversion survient sur le client ou sur le serveur, pour décider
ensuite des règles qui s'appliquent.
Office Access 2000 ADP est un exemple de client qui convertit la date, l'heure ou les valeurs
de devise. Dans la mesure où Access fonctionne avec OLE DB, toutes les opérations d'Office
Access 2000 sont régies par les règles COM qui utilisent les paramètres régionaux de
l'ordinateur client.
Les fournisseurs OLE DB tels que le fournisseur Microsoft OLE DB pour SQL Server
convertiront convenablement une date COM valide en une date SQL Server. Il est
souhaitable, dans la mesure du possible, de ne pas recourir aux formats de date stockés dans
des chaînes. Ce type de fonctionnalité peut ne plus fonctionner si les paramètres régionaux du
client changent.
SQL Server 2005 Integration Services
SQL Server 2005 Integration Services remplace les services Data Transformation Services de
SQL Server 2000. Integration Services offrent des fonctionnalités largement améliorées
d'importation, d'exportation et de transformation de données multilingues. Integration
Services prend en charge l'analyse et la manipulation des données multilingues et tous les
paramètres régionaux de Windows, et fournissent des options de comparaison spécialisées
pour le tri et la comparaison des données de chaîne.
Paramètres régionaux dans les packages Integration Services
Integration Services prend en charge les paramètres régionaux au niveau de la tâche, du
conteneur, de l'objet de package et du composant de flux de données. Vous pouvez également
définir les paramètres régionaux des gestionnaires d'événements et de certaines sources et
destinations.
Un package peut utiliser plusieurs paramètres régionaux différents. Par exemple, le package
peut utiliser les paramètres régionaux de l'anglais (États-Unis) tandis qu'une tâche du package
utilise les paramètres régionaux de l'allemand (Allemagne) et une autre tâche utilise les
paramètres régionaux du japonais (Japon).
Vous pouvez utiliser tous les paramètres régionaux Windows dans un package Integration
Services. Les paramètres régionaux sont définis lors de la création du package. Sauf en cas
d'utilisation par le package de configurations spécifiques pour la mise à jour des propriétés
des paramètres régionaux, le comportement du package est assuré d'être identique lors du
déploiement sur des ordinateurs utilisant des options régionales et de langue différentes de
celles de l'environnement de développement.
Définition des paramètres régionaux
Integration Services n'utilise pas la page de code pour déduire des règles spécifiques aux
paramètres régionaux pour le tri des données ou l'interprétation des données de date, d'heure
ou décimales. La transformation lit plutôt les paramètres régionaux définis par la propriété
LocaleID sur le composant de flux de données, la tâche de flux de données, le conteneur ou le
package.
Par défaut, les paramètres régionaux d'une transformation sont hérités de sa tâche de flux de
données, qui hérite elle-même ceux-ci du package. Si la tâche de flux de données se trouve
dans un conteneur tel que le conteneur de boucle For, elle hérite ses paramètres régionaux du
conteneur.
Vous pouvez également spécifier des paramètres régionaux pour un gestionnaire de
connexions de fichiers plats ou de fichiers plats multiples.
Vous pouvez modifier les paramètres régionaux ou la page de code d'un objet en utilisant
l'éditeur de l'objet de flux de données ou de flux de contrôle. Pour l'objet de package, vous
devez définir des propriétés telles que LocaleID dans la fenêtre Propriétés.
Figure 14. Spécification des paramètres régionaux d'un package
Notez que la propriété CodePage n'est pas disponible pour l'objet de package. Cela est dû au
fait que la page de code ne s'applique pas à l'objet de package, mais uniquement aux sources,
aux destinations ou aux transformations.
Utilisation des données de fichiers plats
Lors de l'utilisation de données sources d'un fichier plat, il est important de comprendre
comment le gestionnaire de connexions de fichiers plats interprète les données de fichier plat.
Si la source de fichier plat est de type Unicode, le gestionnaire de connexions de fichiers plats
définit toutes les colonnes comme [DT_WSTR] avec une largeur de colonne par défaut de 50.
Si la source du fichier plat est codée avec le codage ANSI, les colonnes sont définies comme
[DT_STR] avec une largeur de colonne de 50. Vous devrez probablement modifier ces
valeurs par défaut pour rendre les types de colonnes de chaînes plus adaptés à vos données.
Pour ce faire, examinez le type de données de la destination dans laquelle les données seront
écrites. Ensuite, choisissez le type correct dans le gestionnaire de connexions de fichiers plats.
Sachez qu'en important des données à partir de fichiers plats ou en exportant des données vers
ceux-ci, certaines propriétés du package, de la connexion et des tâches de transformation de
données sont définies automatiquement en fonction des paramètres régionaux. Vous pouvez
facilement remplacer ces paramètres, ce qui peut être nécessaire si vos données contiennent
des informations qui pourraient être affectées par les paramètres régionaux. L'absence de
modification des paramètres régionaux du fichier plat source ou de destination peut avoir des
effets inattendus.
Par exemple, le didacticiel d'Integration Services livré avec SQL Server 2005 contient un
scénario d'importation de données à partir d'un fichier plat. Le fichier contient une colonne
BirthDate qui utilise l'un des formats de date par défaut pour les paramètres régionaux
Anglais (États-Unis). Si vous exécutez ce didacticiel sur un ordinateur qui utilise des
paramètres régionaux différents, le package qui importe les données peut ne pas s'exécuter car
il ne peut pas analyser les données de date. Dans ce cas, pour faire fonctionner le package, il
suffit de modifier le package, les objets de flux de données et les sources ou destinations
apparentées, pour vous assurer qu'ils utilisent les paramètres régionaux corrects.
Figure 15. Définition des paramètres régionaux et de la page de code par défaut pour un
fichier plat (cliquez sur l'image pour l'agrandir)
Analyse des données de texte
Lorsque les services Intégration Services chargent du texte à partir d'un fichier plat ou d'une
autre source, ils analysent le texte conformément à un ensemble de routines d'analyse
prédéfinies : l'analyse rapide ou l'analyse standard.
L'analyse rapide se compose d'un ensemble de routines rapides et simples ne prenant pas en
charge les conversions de type de données spécifiques à des paramètres régionaux et prenant
uniquement en charge les formats de date et d'heure les plus fréquemment utilisés. L'analyse
rapide n'effectue pas d'analyse spécifique aux paramètres régionaux, ne reconnaît pas les
caractères spéciaux des données de devises et ne peut pas convertir la représentation
hexadécimale ou scientifique des entiers.
L'analyse standard est un ensemble riche de routines d'analyse qui prend en charge toutes les
conversions de type de données qui sont fournies par les API d'automatisation de conversion
de type de données disponibles dans Oleaut32.dll et Ole2dsip.dll.
Lorsque vous créez un flux de données, vous pouvez spécifier si les colonnes de résultat de la
transformation utilisent des routines rapides indépendantes des paramètres régionaux fournies
par Microsoft SQL Server 2005 Integration Services (SSIS) ou des routines d'analyse standard
tenant compte des paramètres régionaux.
Si le flux de données du package nécessite une analyse dépendant des paramètres régionaux,
l'analyse standard est recommandée à la place de l'analyse rapide. Par exemple, l'analyse
rapide ne reconnaît pas les données dépendantes des paramètres régionaux incluant des
symboles décimaux tels que la virgule, les formats de date différents d'année-mois-jour et les
symboles de devises.
Pour plus d'informations sur les différents formats de données pris en charge par l'analyse
rapide et l'analyse standard, consultez la section Analyse des données dans la documentation
en ligne de SQL Server 2005.
Analyse rapide spécifiée au niveau de la colonne. Dans la source Flat File et la transformation
Data Conversion, vous pouvez choisir d'utiliser l'analyse rapide des colonnes de sortie. Les
entrées et les sorties peuvent inclure des colonnes dépendantes ou indépendantes des
paramètres régionaux. Cependant, l'analyse rapide est uniquement disponible avec l'utilisation
de la source Flat File ou de la transformation Data Conversion.
Options de comparaison
Les paramètres régionaux fournissent les règles de base pour la comparaison de données de
chaîne dans un flux de données. Par exemple, les paramètres régionaux spécifient la position
de tri de chaque lettre de l'alphabet. Cependant, ces règles peuvent ne pas être suffisantes pour
les comparaisons que vous voulez effectuer et Integration Services prend en charge une série
d'options de comparaison avancées qui s'étendent au-delà des règles de comparaison des
paramètres régionaux. Par exemple, si vous choisissez d'ignorer les caractères sans
espacement, « a » et « á » sont équivalents en ce qui concerne la comparaison.
Les comparaisons de chaînes constituent un élément important d'un grand nombre des
transformations exécutées par Integration Services et sont également utilisées dans
l'évaluation d'expressions dans les variables et dans les expressions de propriétés. Par
exemple :



La transformation Conditional Split peut utiliser les comparaisons de chaînes dans des
expressions pour déterminer la sortie vers laquelle envoyer une ligne de données.
La transformation Derived Column peut utiliser les comparaisons de chaînes dans des
expressions pour générer de nouvelles valeurs de colonnes.
Les transformations Sort, Aggregate, Fuzzy Grouping et Fuzzy Lookup peuvent être
personnalisées pour modifier la façon dont les chaînes sont comparées au niveau de la
colonne. Vous pourriez par exemple spécifier qu'une recherche néglige la casse, mais
traite les caractères accentués et non accentués comme des caractères différents.
En fonction des données et de la configuration de la transformation, le traitement suivant peut
survenir pendant la comparaison des données de chaîne :



Conversion des données en Unicode. Si les données source ne sont pas déjà Unicode,
les données sont automatiquement converties en Unicode avant que la comparaison ait
lieu.
Utilisation des paramètres régionaux pour appliquer des règles spécifiques à ceux-ci
pour interpréter la date, l'heure, les données décimales et l'ordre de tri.
Application d'options de comparaison au niveau de la colonne pour modifier la
sensibilité des comparaisons.
Modification des options de comparaison
Integration Services prennent en charge un ensemble d'options de comparaison avancées qui
peuvent être définies au niveau de la colonne. Par exemple, l'une des options de comparaison
vous permet d'ignorer les caractères sans espacement. L'effet de cette option consiste à
négliger les signes diacritiques tels que les accents, ce qui rend « a » et « á » identiques en ce
qui concerne la comparaison.
Vous pouvez définir les options de comparaison suivantes dans les transformations Sort,
Aggregate, Fuzzy Grouping et Fuzzy Lookup :






Ignorer la casse
Ignorer les caractères kana
Ignorer la largeur de caractère
Ignorer les caractères sans espacement
Ignorer les symboles
Trier les signes de ponctuation en tant que symboles
Les transformations Fuzzy Grouping et Fuzzy Lookup incluent également l'option
FullySensitive pour la comparaison des données. Cet indicateur de comparaison, uniquement
disponible dans l'éditeur avancé, indique que toutes les options de comparaison doivent
s'appliquer.
Sources et destinations des données
Dans la plupart des cas, Integration Services peut identifier les paramètres régionaux corrects
à partir de la source des données. Si Integration Services fournit une page de code inattendue
ou si le package accède à une source de données en utilisant un fournisseur qui ne fournit pas
d'informations suffisantes pour déterminer la page de code correcte, vous pouvez spécifier
une page de code par défaut dans la source et la destination OLE DB. Les pages de code par
défaut sont utilisées à la place des pages de code fournies par Integration Services.
Les fichiers n'ont pas de pages de code. Au lieu de cela, les gestionnaires de connexion de
fichier plat et de fichiers plats multiples qu'un package utilise pour se connecter aux données
du fichier incluent une propriété pour la spécification de la page de code du fichier. La page
de code peut être définie au niveau du fichier uniquement et non au niveau de chaque colonne.
En fonction des opérations que la transformation exécute et de sa configuration, les données
de chaîne peuvent être converties en type de données DT_WSTR, qui est une représentation
Unicode de caractères de chaîne.
Les données de chaîne de type DT_STR sont converties en Unicode à l'aide de la page de
code de chaque colonne. Integration Services prend en charge les pages de code au niveau de
chaque colonne et chaque colonne peut être convertie en utilisant une page de code différente.
Conversion explicite de données de chaîne en Unicode
Les flux de données des packages extraient et chargent les données. Les flux de données
peuvent accéder aux données dans des magasins de données hétérogènes, qui peuvent utiliser
une variété de types de données personnalisés et standard. Dans un flux de données, les
sources Integration Services effectuent le travail d'extraction des données, d'analyse des
données de chaîne et de conversion des données en un type de données Integration Services.
Les transformations suivantes peuvent analyser des données pour les convertir en type de
données différent ou créer des copies de colonnes avec des types de données différents. Les
expressions utilisées dans les composants peuvent également associer des arguments et des
opérandes à des types de données différents. Enfin, lorsque les données sont chargées dans un
magasin de données, la destination peut analyser les données pour les convertir en un type de
données qu'elle utilise.
Lorsque les données entrent dans un flux de données d'un package, la source qui extrait les
données les convertit en un type de données Integration Services. Les données numériques
reçoivent un type de données numérique, les données de chaîne reçoivent un type de données
de caractère et les dates reçoivent un type de données de date. Les autres données, telles que
les GUID et les BLOBs (objets binaires de grande taille), reçoivent également des types de
données Integration Services appropriés. Si les données sont d'un type de données qui n'est
pas convertible en type Integration Services, une erreur se produit.
Pour plus d'informations sur la conversion de données dans les flux de données, consultez la
section Types de données Integration Services dans la documentation en ligne de
SQL Server 2005.
La transformation Data Conversion vous offre la possibilité de contrôler les conversions : de
changer explicitement de page de code, de changer de format et de convertir les données d'une
colonne d'entrée vers un type de données différent. Vous pouvez appliquer plusieurs
conversions à une colonne d'entrée unique. Les données converties peuvent remplacer les
données originales, mais vous pouvez également les copier vers une nouvelle colonne de
sortie pour les utiliser dans les composants en aval.
Par exemple, un package peut extraire des données de sources multilingues et utiliser ensuite
cette transformation pour convertir les colonnes en type de données requis par le magasin de
données de destination.
Grâce à la transformation Data Conversion, vous pouvez effectuer les types de conversion de
données suivants :

Modifier le type de données.


Définir la longueur de colonne des données de chaîne et la précision et l'échelle des
données numériques.
Spécifier une page de code.
La transformation Character Map est un autre composant utile pour effectuer les conversions
de données de caractère. Elle applique des fonctions de chaîne, telles que la conversion de
minuscules en majuscules, aux données qui sont de type chaîne.
La transformation Character Map peut convertir et remplacer les données des colonnes ou
ajouter une colonne à la sortie de la transformation et placer les données converties dans la
nouvelle colonne. Vous pouvez appliquer des ensembles différents d'opérations de mappage à
une même colonne d'entrée et placer les résultats dans des colonnes différentes. Par exemple,
vous pouvez convertir une même colonne en minuscules comme en majuscules et placer les
résultats dans deux colonnes différentes.
La transformation Character Map prend en charge les opérations de mappage suivantes :
Opération
Inversion d'octets
Pleine chasse
Demi chasse
Hiragana
Katakana
Casse linguistique
Minuscule
Chinois simplifié
Chinois traditionnel
Majuscules
Description
Inverse l'ordre des octets.
Mappe les caractères demi chasse vers des
caractères pleine chasse.
Mappe les caractères pleine chasse vers des
caractères demi chasse.
Mappe les caractères katakana vers des
caractères hiragana.
Mappe les caractères hiragana vers des
caractères katakana.
Applique la casse linguistique au lieu des
règles système. La casse linguistique fait
référence à la fonctionnalité fournie par l'API
Win32 pour le mappage Unicode de casse
simple du turc et d'autres paramètres régionaux.
Convertit les caractères en minuscules.
Mappe les caractères chinois traditionnel vers
des caractères chinois simplifié.
Mappe les caractères chinois simplifié vers des
caractères chinois traditionnel.
Convertit les caractères en majuscules.
Plusieurs opérations peuvent être effectuées dans une transformation. Cependant, certaines
opérations de mappage sont mutuellement exclusives. Dans la plupart des cas, ces exclusivités
sont des exclusivités de bon sens : Vous ne pouvez par exemple par mapper de katakana vers
hiragana tout en mappant de hiragana vers katakana. Pour plus d'informations sur les
mappages exclusifs, consultez la section Transformation Character Map dans la
documentation en ligne de SQL Server 2005.
Remarque : Le mappage peut dans certains cas tronquer les données. Ce problème peut par
exemple survenir lorsque des caractères codés sur un seul octet sont mappés vers des
caractères avec une représentation codée sur plusieurs octets. Lorsque vous effectuez des
conversions de données, utilisez les visionneuses de données pour analyser les
transformations des données et les résultats d'erreur afin de diriger les données tronquées ou
fausses vers une sortie différente. Pour plus d'informations, consultez la section Gestion des
erreurs dans les données dans la documentation en ligne de SQL Server 2005.
Prise en charge des caractères supplémentaires dans SSIS
Integration Services gère les paires de substitution de manière transparente. Par conséquent, à
moins qu'une source de données, une destination de données ou une transformation modifie la
taille d'une chaîne, les caractères de la paire de substitution seront gérés de manière identique
à tous les autres caractères Unicode. Les fonctions ou fonctionnalités qui renvoient la taille
d'une chaîne doivent traiter les caractères des paires de substitution comme deux caractères
Unicode distincts et non définis. Les fonctions assurant cette opération sont les fonctions de
chaîne LEN et SUBSTRING.
Pour afficher des caractères supplémentaires, l'utilisateur doit personnaliser Business
Intelligence Development Studio pour installer une police qui prend en charge les extensions
correspondant à ces caractères. Cependant, comme les caractères supplémentaires sont
uniquement pris en charge par SQL Server en tant que données et non comme métadonnées,
les emplacements dans lesquels vous pourriez avoir besoin d'afficher ces caractères se limitent
aux aperçus de données, à la clause WHERE des requêtes, etc.
Modification dynamique des paramètres régionaux avec les configurations
Si un package doit utiliser des paramètres régionaux différents lorsqu'il est déployé sur des
serveurs différents, vous pouvez créer des configurations qui fournissent les paramètres
régionaux mis à jour à utiliser lors de l'exécution du package.
Les configurations sont des paires « attribut-valeur » qui vous permettent de définir des
propriétés et des variables lors de l'exécution depuis l'extérieur de l'environnement de
développement. En incorporant ces configurations au développement, vous pouvez créer des
packages à la fois souples et faciles à déployer et à distribuer. Integration Services permet les
types de configuration suivants :





fichier de configuration XML ;
variable d'environnement ;
entrée de Registre ;
variable de package parent ;
table SQL Server.
Pour une flexibilité supplémentaire, Integration Services prend en charge l'utilisation de
configurations indirectes. Cela signifie que vous utilisez une variable d'environnement pour
spécifier l'emplacement de la configuration, qui à son tour fait référence à des valeurs.
Un fichier de configuration XML peut inclure des configurations pour plusieurs propriétés et,
sous certaines conditions, contenir les configurations de plusieurs packages.
Plusieurs nouveaux didacticiels Integration Services ont été publiés pour vous guider dans le
processus de création et de test des configurations, ainsi que dans la mise en place d'un
utilitaire de déploiement pour la création de nouveaux packages contenant des configurations
dynamiques. Nous vous recommandons de consulter ces didacticiels pour apprendre comment
mettre à jour les pages de code, les options de conversion ou d'autres paramètres
internationaux de façon dynamique en utilisant des configurations et en déployant ensuite les
packages.
Didacticiel Création d'un package ETL simple
Le didacticiel Création d'un package ETL simple vous guide tout au long des tâches
suivantes.




Création d'un package Integration Services simple et ajout d'une boucle.
Présentation de l'Assistant Package Configuration Wizard et description du format des
configurations XML.
Création d'un package de configuration qui modifie le répertoire contenant les fichiers
texte devant être parcourus en boucle.
Test de la configuration grâce à la modification de la valeur d'une variable depuis
l'extérieur de l'environnement de développement et au pointage de la propriété
modifiée vers un nouveau dossier de données exemplaire. Lors de l'exécution suivante
du package, le fichier de configuration met à jour le dossier des fichiers.
Didacticiel Déploiement des packages
Vous trouverez le didacticiel Déploiement des packages utile pour l'apprentissage des tâches
suivantes.




Utilisation d'une combinaison de fichiers de configuration XML et de configurations
indirectes pour la mise à jour des chaînes de connexion de fichiers journaux, les
fichiers texte et les emplacements des fichiers XML et XSD que le package utilise au
moment de l'exécution.
Création d'un lot de déploiement à utiliser pour l'installation des packages. Le paquet
de déploiement se compose des fichiers de package et des autres éléments que vous
avez ajoutés au projet Integration Services, des dépendances de package incluses
automatiquement par Integration Services et de l'utilitaire de déploiement que vous
avez généré.
Exécution de l'Assistant Package Installation Wizard pour l'installation des packages
et des dépendances des packages. Les packages sont installés dans la base de données
SQL Server msdb et les fichiers de prise en charge sont installés dans le système de
fichiers.
Mise à jour de la configuration pour utiliser de nouvelles valeurs qui permettent aux
packages de s'exécuter avec succès dans le nouvel environnement.
Utilisation d'utilitaires de ligne de commande avec les
données multilingues
Cette section fournit des informations de base sur certains utilitaires de ligne de commande
fournis avec SQL Server 2005. L'utilitaire bcp a été mis à jour pour fournir des
fonctionnalités utiles dans les scénarios multilingues et inclut la prise en charge des formats
XML. Sqlcmd est un nouvel utilitaire qui simplifie l'écriture de scripts et vous permet de
contrôler la page de code des fichiers de scripts.
bcp
Lorsque vous souhaitez importer ou exporter des données dans une page de code particulière,
vous pouvez utiliser l'utilitaire bcp. L'utilitaire bcp copie les données entre une instance de
Microsoft SQL Server et un fichier de données dans un format spécifié par l'utilisateur.
Dans SQL Server 2005, bcp applique de nouvelles validations et vérifications de données qui
risquent de provoquer l'échec des scripts existants s'ils sont exécutés sur des données non
valides d'un fichier de données. Par exemple, bcp vérifie maintenant :


que la représentation native des types de données real ou float est valide ;
que les données Unicode ont une longueur de données paire.
Remarque : Certaines formes de données non valides qui pouvaient être importées en bloc
dans les versions précédentes de SQL Server peuvent désormais ne pas réussir à se charger.
Dans les versions précédentes, l'échec ne survenait pas avant qu'un client essaie d'accéder aux
données non valides. La raison de cette nouvelle validation est que la validation avant le
chargement des données réduit le risque de mauvaise surprise lorsque vous interrogez les
données après le chargement en bloc.
L'utilitaire bcp prend en charge les indicateurs suivants pour une conversion sans perte de
données :
Indicateur Signification
Explication et remarques
-C xxx
Spécificateur de page xxx peut spécifier une page de code, ANSI, OEM ou
de code
RAW. Cette option est prise en charge pour la
compatibilité avec les versions antérieures de SQL Server.
Pour SQL Server 7.0 et versions ultérieures. Microsoft
recommande la spécification d'un nom de classement pour
chaque colonne d'un fichier de format.
ANSI : Microsoft Windows (ISO 1252).
OEM : page de code par défaut utilisée par le client. Il
s'agit de la page de code par défaut utilisée si -C n'est pas
spécifié.
RAW : Aucune conversion de page de code vers une autre
n'est effectuée. C'est l'option la plus rapide.
-N
Utiliser le format
Unicode natif
Code_page : Utiliser cette option uniquement si les
données contiennent des colonnes char, varchar ou text
avec des valeurs de caractères supérieures à 127 ou
inférieures à 32.
Utilise les types de données natifs (de la base de données)
pour toutes les données de type non caractère et le format
de caractère Unicode pour toutes les données de type
caractère.
-w
Utiliser le format de
caractères Unicode
Cette option offre une alternative hautes performances à
l'option -w et est prévue pour le transfert de données d'une
instance de SQL Server vers une autre à l'aide d'un fichier
de données. Elle ne vous avertit pas pour chaque champ.
Utilisez cette option lorsque vous transférez des données
contenant des caractères étendus ANSI et que vous voulez
tirer parti des performances du mode natif. Elle ne peut
pas être utilisée avec SQL Server 6.5 ou les versions
antérieures.
Utilise le format de données de caractères Unicode pour
toutes les colonnes.
Cette option n'affiche pas une invite pour chaque champ.
Elle utilise nchar comme type de stockage, aucun préfixe,
\t (caractère de tabulation) comme séparateur de champs et
\n (caractère de nouvelle ligne) comme terminateur de
ligne. Elle ne peut pas être utilisée avec SQL Server 6.5
ou les versions antérieures.
Vous pouvez également utiliser les fichiers de format et spécifier des classements au niveau
de chaque colonne. Si vous ne spécifiez pas -C, -N ou -w, bcp demandera les informations
concernant le classement et la page de code concernant chaque colonne avant d'exécuter
l'importation ou l'exportation. Vous serez ensuite invité à enregistrer ces informations dans un
fichier de format, comme illustré ici :
9.0
9
1
2
3
4
5
6
7
8
9
SQLCHAR
SQLCHAR
SQLCHAR
SQLCHAR
SQLCHAR
SQLCHAR
SQLCHAR
SQLCHAR
SQLBIT
0
0
0
0
0
0
0
0
0
11
40
20
12
40
20
2
5
1
""1
au_id
Latin1_General_CI_AI
""
2
au_lname
Latin1_General_CI_AI
""
3
au_fname
Latin1_General_CI_AI
""
4
phone
Latin1_General_CI_AI
""
5
address
Latin1_General_CI_AI
""
6
city
Latin1_General_CI_AI
""
7
state
Latin1_General_CI_AI
""
8
zip
Latin1_General_CI_AI
""
9
contract
""
Pour plus d'informations sur les fichiers de format, consultez la section Comprendre les
fichiers de format non XML dans la documentation en ligne de SQL Server 2005.
SQL Server 2005 a introduit un fichier au format XML pour bcp. Les fichiers au format XML
présentent de nombreux avantages : Ils contiennent des descriptions des colonnes de la table
correspondante et les types de données des colonnes cibles. Les fichiers XML sont faciles à
lire, à créer et à étendre. Vous pouvez créer un fichier au format XML en utilisant bcp, avec
l'option –x. Après la création du fichier de format, vous pouvez l'utiliser pour importer ou
exporter des données avec bcp et l'option -f.
Le tableau suivant répertorie les types de données qui peuvent être importés ou exportés avec
bcp. Le classement est le classement par défaut spécifié pour la colonne et il peut avoir été
hérité de la base de données ou du serveur.
Type
C
T
I
S
T
F
M
B
D
X
I
D
r
M
n
E
W
W
U
Nom complet
char
text
int
smallint
tinyint
float
money
bit
datetime
binary
image
smalldatetime
real
smallmoney
numeric
decimal
nchar
ntext
uniqueidentifier
Notez que les types de données varchar et nvarchar ne sont pas répertoriés dans le tableau.
Pour l'utilitaire bcp, les types de données char et nchar doivent être utilisés à leur place,
respectivement.
Enfin, bcp prend en charge l'indicateur -R pour l'activation régionale. Cet indicateur a le
même effet que l'option ODBC Utiliser les paramètres régionaux, ce qui peut affecter
l'interprétation des données de date/heure, de nombres et de devises qui sont stockées dans
des champs non textuels.
sqlcmd
L'utilitaire sqlcmd est nouveau dans SQL Server 2005 et fournit des fonctionnalités
précédemment fournies par une combinaison d'osql, d'isql, de fichiers batch et de VBScript.
Cet utilitaire utilise OLE DB pour exécuter les lots Transact-SQL.
Vous pouvez exécuter des requêtes ad hoc de façon interactive depuis une fenêtre d'invite de
commande ou exécuter un script qui contient des instructions Transact-SQL ou des
procédures système. Vous pouvez créer des fichiers de script et exécuter ensuite les scripts
dans l'invite de commande, dans l'Éditeur de requête dans le mode SQLCMD, dans un fichier
script Windows ou dans une étape de travail de système d'exploitation (Cmd.exe) d'une tâche
de l'Agent SQL Server.
Vous pouvez utiliser l'option -f pour spécifier la page de code d'entrée et la page de code de
sortie.
Le numéro de page de code doit être une valeur numérique qui spécifie une page de code
Windows installée. Si aucune page de code n'est spécifiée, sqlcmd utilise la page de code du
système actuel pour les fichiers d'entrée et de sortie. Cependant, vous pouvez utiliser l'option u pour faire en sorte que le fichier de sortie soit stocké dans le format Unicode, quel que soit
le format du fichier d'entrée.
Les exemples suivants démontrent cette syntaxe. Le fichier script Myscript.sql contient la
requête suivante :
'USE AdventureWorks; GO; SELECT * FROM
Production.vProductAndDescription; ORDER BY CultureID;'
Le premier exemple exécute la requête et enregistre le résultat dans un fichier dans Unicode.
Le deuxième exemple exécute la même requête, mais le fichier de sortie est enregistré dans la
page de code ayant l'ID 950. Une erreur peut survenir si la page de code n'est pas disponible.
sqlcmd -i C:\Temp\MyScript.sql -o C:\temp3\MyOutput1.txt -u
sqlcmd -i C:\ Temp\MyScript.sql -f1252 -o C:\temp3\MyOutput2.txt -f950
Sqlcmd reconnaît automatiquement les fichiers d'entrée Unicode big-endian et little-endian.
Si l'option -u a été spécifiée, la sortie sera toujours Unicode little-endian.
On suppose que les fichiers d'entrée multiples sont de la même page de code. Les fichiers
d'entrée Unicode et non Unicode peuvent être mélangés.
Vous pouvez créer et modifier des scripts sqlcmd en utilisant l'Éditeur de requête dans
SQL Server Management Studio (SSMS). Cependant, SSMS utilise Microsoft .NET SqlClient
pour l'exécution, tandis que sqlcmd utilise le fournisseur OLE DB lorsque vous exécutez un
script à partir de la ligne de commande. Par conséquent, vous pourriez constater un
comportement différent lorsque vous exécutez la même requête dans
SQL Server Management Studio dans le mode SQLCMD et dans l'utilitaire sqlcmd.
Fonctionnalités internationales dans
SQL Server Analysis Services
Microsoft SQL Server 2005 Analysis Services prend en charge toutes les langues qui sont
prises en charge par les systèmes d'exploitation Microsoft Windows. Analysis Services utilise
des identificateurs de langue Windows pour spécifier la langue sélectionnée pour les instances
et les objets Analysis Services. Un identificateur de langue Windows correspond à une
combinaison d'identificateurs de langues principales et de sous-langues Windows. Par
exemple, si vous sélectionnez anglais (États-Unis) pendant l'installation, l'identificateur de
langue Windows correspondant, 0x0409 (ou 1033), est spécifié dans l'élément Langue du
fichier des paramètres de configuration pour l'instance d'Analysis Services.
Traductions
En plus de spécifier la langue et le classement par défaut utilisés par une instance d'Analysis
Services, vous pouvez également fournir la prise en charge multilingue pour les objets
individuels Analysis Services, notamment les cubes, les groupes de mesures, les dimensions,
les hiérarchies et les attributs, en définissant une traduction associée à un objet Analysis
Services.
Vous pouvez utiliser Business Intelligence Development Studio pour définir les traductions
pour la légende, la description et les types de comptes pour une base de données Analysis
Services. Lorsque vous utilisez des traductions, les applications clientes peuvent recevoir des
objets Analysis Services dans une langue et un classement différents.
Les paramètres de langue et de classement par défaut pour une instance d'Analysis Services
spécifient les paramètres utilisés pour les données et les métadonnées si la traduction pour un
identificateur de langue spécifique n'est pas fournie pour un objet Analysis Services ou si une
application cliente ne spécifie pas d'identificateur de langue lors de la connexion à une
instance d'Analysis Services.
Notez que, bien que les traductions fournissent informations d'affichage pour les noms des
objets Analysis Services, les identificateurs ne sont pas traduits. Pour assurer la portabilité sur
plusieurs langues, utilisez les identificateurs et clés pour les objets Analysis Services plutôt
que les légendes et noms traduits. Utilisez par exemple des clés de membres plutôt que des
noms de membres pour les instructions et scripts Multidimensional Expressions (MDX).
Si une application cliente demande des informations dans un identificateur de langue spécifié,
l'instance d'Analysis Services tente de résoudre les données et métadonnées pour les objets
Analysis Services avec l'identificateur de langue le plus proche possible. Si l'application
cliente ne spécifie pas de langue par défaut ou si elle spécifie l'identificateur des paramètres
régionaux neutre (0) ou l'identificateur de langue par défaut du processus (1024), Analysis
Services utilise la langue par défaut pour l'instance afin de renvoyer les données et
métadonnées pour les objets d'Analysis Services.
Si l'application cliente spécifie un identificateur de langue autre que l'identificateur de langue
par défaut, l'instance effectue une itération sur toutes les traductions disponibles pour tous les
objets disponibles. Si l'identificateur de langue spécifié correspond à l'identificateur de langue
d'une traduction, Analysis Services renvoie cette traduction. Si aucune correspondance n'est
trouvée, Analysis Services tente d'utiliser l'une des méthodes suivantes pour renvoyer des
traductions avec un identificateur de langue le plus proche de l'identificateur de langue
spécifié.
Pour les identificateurs de langue suivants, Analysis Services tente d'utiliser un autre
identificateur de langue si aucune traduction n'est définie pour l'identificateur de langue
spécifié.
Identificateur de langue spécifié
Autre identificateur de langue
3076: Chinois (RAS de Hong Kong, RPC) 1028: Chinois (Taïwan)
5124: Chinois (RAS de Macao)
1028: Chinois (Taïwan)
1028: Chinois (Taïwan)
Langue par défaut
4100: Chinois (Singapour)
2052: Chinois (RPC)
2074: Croate
Langue par défaut
3098: Croate (Cyrillique)
Langue par défaut
Pour tous les autres identificateurs de langue spécifiés, Services Analysis extrait la langue
principale de l'identificateur de langue spécifié et récupère l'identificateur de langue indiqué
par Windows comme étant la meilleure correspondance pour la langue principale. Si aucune
traduction pour le meilleur identificateur de langue n'est trouvée ou si l'identificateur de
langue spécifié est la meilleure correspondance pour la langue principale, la langue par défaut
est utilisée.
Classements dans Analysis Services
Analysis Services utilise des classements Windows pour spécifier le classement sélectionné
pour les instances et les objets Analysis Services. Lorsque vous spécifiez un classement
Windows pour Analysis Services, l'instance d'Analysis Services utilise les mêmes pages de
code et règles de tri et de comparaison qu'une application s'exécutant sur un ordinateur pour
lequel vous avez spécifié les paramètres régionaux Windows associés. Par exemple, le
classement Windows français pour Analysis Services correspond aux attributs de classement
des paramètres régionaux français pour Windows.
Il y a plus de paramètres régionaux Windows qu'il y a de classements Windows définis pour
Analysis Services. Les noms de paramètres régionaux Windows sont basés sur un
identificateur de langue, tel que Anglais, et un identificateur de sous-langue, tel que ÉtatsUnis ou Australie. Cependant, de nombreuses langues utilisent les mêmes alphabets et règles
de tri et de comparaison des caractères.
Par exemple, 33 paramètres régionaux Windows, notamment tous les paramètres régionaux
Windows Portugais et Anglais, utilisent la page de code Latin1 (1252) et suivent un ensemble
de règles commun pour trier et comparer les caractères. Le classement SQL Server Windows
Latin1_General, basé sur cette page de code et les règles de tri associées, prend en charge ces
33 paramètres régionaux Windows. De plus, les paramètres régionaux Windows spécifient
des attributs qui ne sont pas couverts par les classements Windows Analysis Services, tels que
les formats de devise, de date et d'heure. Comme les pays et régions tels que l'Australie et les
États-Unis ont des formats de devise, de date et d'heure différents, ils requièrent des
classements Windows différents. Ils n'ont cependant pas besoin de classements Windows
Analysis Services différents, parce qu'ils utilisent le même alphabet et les mêmes règles de tri
et de comparaison des caractères.
Bien que plusieurs identificateurs de langue puissent être spécifiés pour les objets Analysis
Services, le même classement Windows Analysis Services est utilisé pour tous les objets
Analysis Services, avec une seule exception, quel que soit l'identificateur de langue. La seule
exception à cette fonctionnalité est la propriété CaptionColumn d'un attribut dans une
dimension de base de données, pour laquelle vous pouvez spécifier un classement Windows
Analysis Services pour compiler les membres de l'attribut spécifié.
Options d'ordre de tri dans Analysis Services
Si la même langue est utilisée par tous les utilisateurs pour votre instance d'Analysis Services,
sélectionnez le classement qui prend en charge la langue par défaut spécifiée pour votre
instance. Si plusieurs langues sont utilisées, choisissez le classement qui propose la meilleure
prise en charge pour les exigences des diverses langues. Par exemple, si les utilisateurs de
votre instance parlent surtout des langues d'Europe de l'ouest, sélectionnez le classement
Latin1_General classement.
Plusieurs options d'ordre de tri peuvent être appliquées au classement Windows Analysis
Services spécifié pour définir davantage les règles de tri et de comparaison en fonction du
respect de la casse, des accents, du kana et de la largeur. Les options d'ordre de tri sont les
mêmes pour le moteur de base de données SQL Server : Vous pouvez définir la sensibilité à la
casse et à la largeur, aux accents et au type de kana.
Si vous utilisez l'identificateur de langue Anglais (États-Unis) (0x0409 ou 1033) comme
langue par défaut pour l'instance d'Analysis Services, vous pouvez obtenir des avantages de
performances supplémentaires en définissant la propriété de configuration
EnableFast1033Locale. Il s'agit d'une propriété de configuration avancée qui est disponible
uniquement pour cet identificateur de langue. La définition de cette valeur sur true permet à
Analysis Services d'utiliser un algorithme plus rapide pour hacher et comparer les chaînes.
Remarque : La possibilité d'avoir des classements différents dans des parties différentes de
structures de données hiérarchiques constituant un magasin de données n'est pas prise en
charge. Bien que cela ne soit généralement pas utile dans l'analyse des données, il y a des cas
tels que le partitionnement alphabétique des données dans lesquels cela pourrait être utile.
Dans de tels cas, vous devez proposer une autre façon de partitionner les données, qui définit
explicitement l'ordre et les partitions et ne suppose pas l'ordre des lettres. Cela serait
également très utile pour l'affichage de données hiérarchiques. Si vous avez besoin d'une telle
fonctionnalité, vous trierez le sous-ensemble des données renvoyées à partir de la source
OLAP.
Prise en charge de plusieurs devises
Analysis Services fournit une prise en charge de la conversion de devises dans des cubes qui
contiennent plusieurs devises. Pour pouvoir définir une conversion de devises dans un cube,
vous devez commencer par définir au moins une dimension de devise, au moins une
dimension de temps et au moins un groupe de mesures de taux. À partir de ces objets,
l'Assistant Business Intelligence Wizard peut récupérer les données et métadonnées utilisées
pour construire la dimension de devise des rapports et créer un script MDX pour offrir une
fonctionnalité de conversion de devises.
Pour pouvoir implémenter les conversions de devises, vous devez définir les éléments
suivants :
Terme
Devise pivot
Devise locale
Définition
Devise par rapport à laquelle les taux de change sont entrés dans le
groupe de mesure de taux.
Devise utilisée pour stocker les transactions sur lesquelles les mesures
convertibles sont basées.
La devise locale peut être identifiée par l'un des attributs suivants :

Un identificateur de devise dans la table de faits stockée avec
la transaction. C'est souvent le cas dans les applications

Devise de rapports
Direction du taux de
change
Éléments convertis
Type de conversion
bancaires, où la transaction elle-même identifie la devise
utilisée pour cette transaction.
Un identificateur de devise associé à un attribut dans une table
de dimension, qui est ensuite associé à une transaction dans la
table de faits. C'est souvent le cas dans les applications
financières, où un emplacement ou un autre identificateur, tel
qu'une filiale, identifie la devise utilisée pour une transaction
associée.
Devise vers laquelle les transactions sont converties à partir de la
devise pivot.
Indique si le multiplicateur est appliqué à la devise pivot ou à la
devise d'exemple. La combinaison de la direction du taux de change
et du type de conversion détermine l'opération réalisée sur les mesures
à convertir.
Spécifie l'étendue du calcul de la conversion de devises.
Indique comment les transactions sont stockées et combien de devises
doivent être utilisées dans la conversion.



Un vers plusieurs : Stocke en tant que devise pivot. Convertit
vers plusieurs devises de rapports.
Plusieurs vers un : Stocke en tant que devise locale.
Convertit vers la devise pivot, qui est utilisée comme seule
devise de rapports.
Plusieurs à plusieurs : Stocke en tant que devise locale.
Convertit vers la devise pivot, puis vers plusieurs devises de
rapports.
Vous pouvez ensuite utiliser l'Assistant Business Intelligence Wizard pour produire un script
MDX qui utilise une combinaison de données et métadonnées des dimensions, attributs et
groupes de mesures pour convertir les mesures contenant des données de devises. Pour plus
d'informations sur la manière d'utiliser l'Assistant afin de créer des conversions de devises,
consultez la section Utilisation de conversions de devises (SSAS) dans la documentation en
ligne de SQL Server 2005.
Utilisation de valeurs de date et d'heure dans SSAS
Lorsque vous exécutez des comparaisons et des opérations entre le mois et le jour de la
semaine, utilisez les parties de date et d'heure numériques plutôt que des chaînes de parties de
date et d'heure. Les chaînes de parties de date et d'heure sont déterminées d'une part par
l'identificateur de langue spécifié pour l'instance, et d'autre part par la traduction actuelle
fournie par l'instance pour les membres de la dimension de temps.
Vous devriez exploiter les diverses fonctions de date et d'heure dans MDX pour l'utilisation
de dimensions de temps. Les fonctions de date et d'heure de Visual Basic for Applications
(VBA) sont également très utiles pour le renvoi de parties de date et d'heure numériques
plutôt que les chaînes de nom. Pour les applications clientes, utilisez des chaînes de parties de
date et d'heure littérales lors du renvoi de résultats qui seront affichés pour un utilisateur,
parce que les chaînes sont généralement plus significatives qu'une représentation numérique.
Toutefois, ne codez pas les logiques qui dépendent de l'affichage des noms dans une langue
spécifique.
Prise en charge de XML dans SQL Server 2005
SQL Server 2005 présente SQLXML 4.0, qui offre les mêmes fonctionnalités de base que
SQLXML 3.0, plus des mises à jour supplémentaires pour tenir compte de nouvelles fonctions
introduites dans Microsoft SQL Server 2005.
SQL Server 2005 prend en charge le type de données xml, qui vous permet de stocker des
documents et des fragments XML dans une base de données SQL Server. Un fragment XML
est une instance XML à laquelle il manque un seul élément de premier niveau. Vous pouvez
créer des colonnes et des variables du type xml et stocker des instances de XML dedans, si la
représentation stockée ne dépasse pas 2 Go. Le type de données xml et les méthodes associées
aident à intégrer XML dans l'infrastructure relationnelle de SQL Server.
XML et Unicode
Le type de données xml de SQL Server 2005 implémente le type de données xml standard
d'ISO SQL-2003. Par conséquent, il peut non seulement stocker les documents XML
version 1.0 bien formés, mais également les fragments de contenus XML avec des nœuds de
texte. Le système vérifie que les données sont bien formées, n'a pas besoin que la colonne soit
reliée à des schémas XML et rejette les données qui ne sont pas bien formées.
Dans SQL Server 2005, vous pouvez générer des codes XML de diverses façons : vous
pouvez taper les chaînes de distribution, utiliser l'instruction SELECT avec la clause XLM
FOR, utiliser le chargement en masse ou attribuer le XML à une constante de chaîne. Pour
obtenir des informations sur la façon dont les types chaîne et binaire interagissent avec
l'encodage de documents XML et sur le comportement de l'analyseur XML, consultez la
section Génération d'instances XML dans la documentation en ligne de SQL Server 2005.
Les documents XML peuvent être codés avec des encodages différents ; par exemple, UTF-8,
UTF-16 ou Latin-1252. Vous pouvez spécifier un encodage dans XML de plusieurs façons :



Si vous formatez des données en XML dans un objet ADO Stream et que vous
conservez ensuite le flux, vous pouvez spécifier un encodage de sortie et le bon
encodage sera marqué dans les données formatées XML.
Vous pouvez spécifier un encodage de sortie dans une URL.
Les modèles XML peuvent spécifier un encodage.
Même si vous n'utilisez aucune de ces méthodes, Unicode est pris en charge par défaut et il
fonctionnera correctement.
Remarque : Le type de données xml de SQL Server 2005 ne gère pas l'espace blanc
directement suivant la description de l'espace blanc dans la spécification XML 1.0. Dans
SQL Server, l'espace blanc se trouvant à l'intérieur d'un contenu d'élément est considéré
comme insignifiant s'il survient à l'intérieur d'une séquence de données de caractères à espace
blanc uniquement délimitées par un balisage, tel que des balises de début ou de fin, et ne
constitue pas une entité. (Les sections CDATA sont ignorées). Ce la est dû au fait que
l'analyseur XML dans SQL Server reconnaît uniquement un certain nombre de sousensembles DTD, comme défini dans XML 1.0. Pour plus d'informations sur les sousensembles DTD limités pris en charge dans SQL Server 2005, consultez la section
DISTRIBUTION ET CONVERSION (Transact-SQL) dans la documentation en ligne de
SQL Server 2005.
Updategrams (codes de mise à jour)
Vous pouvez modifier (insérer, mettre à jour ou supprimer) des données dans une base de
données Microsoft SQL Server 2005 à partir d'un document XML existant en utilisant un
updategram ou la fonction Transact-SQL OPENXML. Les codes de mise à jour
(Updategrams) sont conçus pour être adaptés aux textes multilingues et aux méthodes de prise
en charge permettant de spécifier l'encodage.
La fonction OPENXML modifie une base de données en décomposant le document XML
existant et en fournissant un ensemble de lignes qui peut être transmis à une instruction
INSERT, UPDATE ou DELETE. Avec OPENXML, les opérations sont exécutées
directement par rapport aux tables de bases de données. Par conséquent, OPENXML est
particulièrement approprié lorsque les fournisseurs d'ensembles de lignes, tels que les tables,
peuvent apparaître en tant que source.
Comme OPENXML, un updategram permet d'insérer, de mettre à jour ou de supprimer des
données dans la base de données ; cependant, un updategram fonctionne par rapport aux vues
XML fournies par le schéma XSD (ou XDR) annoté. Par exemple, les mises à jour sont
appliquées à la vue XML fournie par le schéma de mappage. Le schéma de mappage, pour sa
part, dispose des informations nécessaires pour associer les éléments et attributs XML aux
tables et colonnes de bases de données correspondantes. L'updategram utilise ces informations
de mappage pour mettre à jour les tables et colonnes de bases de données.
Accès aux données pour les clients XML
Pour utiliser SQLXML 4.0, vous devez également disposer de Microsoft SQL Native Client et
de MDAC 2.6 ou version ultérieure. Lors du déploiement d'une application dépendant de
SQL Native Client, vous devrez redistribuer SQL Native Client avec votre application.
Contrairement à Microsoft Data-Access Components (MDAC), qui est maintenant un
composant du système d'exploitation, SQL Native Client est un composant de
SQL Server 2005. Par conséquent, il importe d'installer SQL Server Native Client dans votre
environnement de développement et de redistribuer SQL Native Client avec votre application.
Dans les versions précédentes de SQLXML, l'exécution de requêtes HTTP était prise en
charge en utilisant les répertoires virtuels SQLXML IIS et le filtre ISAPI SQLXML. Dans
SQLXML 4.0, ces composants ont été supprimés car des fonctionnalités similaires et
redondantes sont maintenant fournies avec les services Web XML natifs dans
SQL Server 2005. Si votre solution nécessite les fonctions de typage de données avancées de
SQL Server 2005, telles que le type de données xml ou les types de données définis par
l'utilisateur et un accès par le Web, vous devrez utiliser une autre solution, telle que les classes
gérées par SQLXML ou un autre type de gestionnaire HTTP, tel que les services Web Native
XML pour SQL Server 2005.
Si vous n'avez pas besoin de ces extensions de type de SQL Server 2005, vous pouvez
continuer à utiliser SQLXML 3.0 pour vous connecter à des installations SQL Server 2005.
La prise en charge ISAPI de SQLXML 3.0 fonctionnera sur SQL Server 2005, mais elle ne
prend pas en charge et ne reconnaît pas le type de données xml ou la prise en charge de type
UDT introduite dans SQL Server 2005.
Pour une présentation du jeu complet des fonctionnalités XML dans SQL Server 2005,
consultez les sections Utilisation de XML dans SQL Server et Méthodes XML recommandées
dans la documentation en ligne de SQL Server 2005.
Pour des informations sur l'utilisation de XML dans des applications clientes, consultez les
sections Utilisation du type de données xml dans des applications et Programmation de
SQLXML 4.0 dans la documentation en ligne de SQL Server 2005.
Améliorations de la recherche de texte intégral
La recherche de texte intégral de SQL Server 2005 inclut une mise à niveau majeure du
service Microsoft Search (MSSearch) vers la version 3.0. Ces améliorations incluent les
fonctionnalités suivantes :




Amélioration considérable des performances de création d'index de texte intégral
Une instance de MSSearch 3.0 par instance de SQL Server, ce qui permet une
installation côte à côte du moteur de texte intégral sur des instances séparées
Améliorations des requêtes, notamment la possibilité de spécifier la langue
Prise en charge de l'indexation de texte intégral et de la recherche du type de données
xml
Instances multiples du moteur de texte intégral
Le service de moteur de texte intégral Microsoft pour SQL Server (MSFTESQL) est basé sur
le service Microsoft Search (MSSearch). Dans SQL Server 2005, un service distinct est
installé par instance de Microsoft SQL Server. Ceci signifie que SQL Server n'a plus besoin
de partager le service MSSearch avec les d'autres produits de serveur utilisant le service
MSSearch. Le fait de disposer d'instances séparées du moteur de texte intégral simplifie
également le processus de gestion et de mise à jour des serveurs. Vous pouvez installer
d'autres produits qui utilisent le service MSSearch, tels que Microsoft Sharepoint Portal
Server, sans craindre qu'une version plus récente du service MSSearch n'affecte le
comportement de la recherche de texte intégral.
La mise à niveau vers la nouvelle version de MSSearch se fait pendant l'installation de
SQL Server 2005. Une instance de SQL Server 2005 est configurée parallèlement à l'ancienne
version de SQL Server et les données sont migrées. Si la recherche de texte intégral était
installée dans l'ancienne version de SQL Server, une nouvelle version de la recherche de texte
intégral est installée automatiquement.
Modifications de formats dans les catalogues de texte intégral
Le format des catalogues de texte intégral a beaucoup changé dans SQL Server 2005. Cette
modification nécessite la reconstruction de tous les catalogues de texte intégral des versions
précédentes de SQL Server. La reconstruction survient automatiquement et ne compromet pas
la mise à niveau. Par conséquent, la reconstruction de catalogues de texte intégral peut
continuer après la mise à niveau.
Lorsque le catalogue de texte intégral est reconstruit, un nouveau dossier est créé sous le
chemin où se trouvait initialement le catalogue de texte intégral. Les fichiers associés aux
catalogues de texte intégral reconstruits sont répertoriés dans ce nouveau dossier.
Options spécifiques à la langue pour la recherche de texte intégral
Dans Microsoft SQL Server 2005, les requêtes de texte intégral peuvent utiliser des langues
autres que la langue par défaut pour la colonne pour rechercher des données de texte intégral.
Tant que la langue est prise en charge et que ses ressources sont installées, la langue spécifiée
dans la clause language_term LANGAGE de la requête CONTAINS, CONTAINSTABLE,
FREETEXT, et FREETEXTTABLE sera utilisée pour la césure de mots, le radical et le
traitement des mots parasites et synonymes.
Lorsque vous créez un index de texte intégral sur une colonne, vous devez choisir la langue de
la colonne. En choisissant une langue, vous définissez des options pour la façon dont le texte
est marqué puis indexé par le moteur de texte intégral. Ces options sont notamment :


Utilisation d'un séparateur de mots spécifique ou du séparateur de mots neutre
Radical basé sur la langue
L'Annexe E contient une liste des langues prenant en charge le radical ou la césure de mots
spécifiques à la langue. Toutes les autres langues utilisent le moteur indépendant de la langue.
Dans ce cas, la césure de mots utilise l'espace blanc pour la séparation et aucun radical n'est
réalisé.
Les séparateurs de mots sont principalement conçus pour traiter du texte brut ; donc, si vous
avez n'importe quel type de balise (HTML, par exemple) dans votre texte, vous risquez de ne
pas obtenir une grande précision linguistique pendant l'indexation et la recherche. Dans ce
cas, vous avez deux solutions : la méthode préférée consiste à stocker les données de texte
dans la colonne varbinary(max) et à indiquer son type de document pour permettre son
filtrage.
Si vous ne pouvez pas enregistrer vos données dans une colonne varbinary(max), vous
pouvez envisager d'utiliser le séparateur de mots neutre. Si possible, vous pouvez également
ajouter des données de balise (telles que la balise « br » dans HTML) à vos listes de mots
parasites. Lorsque les données ne sont pas stockées dans une colonne varbinary(max), aucun
filtre particulier n'est exécuté. En fait, le texte passe par le composant de séparation de mots
tel quel.
Le paramètre d'identificateur des paramètres régionaux du classement Unicode est utilisé sur
tous les types de données éligibles pour l'indexation de texte intégral (par exemple, char,
nchar, etc.). Si vous avez spécifié l'ordre de tri d'une colonne char, varchar ou text à l'aide
d'un paramètre de langue différent de la langue de l'identificateur de paramètres régionaux du
classement Unicode, l'identificateur des paramètres régionaux du classement Unicode
continue d'être utilisé pendant l'indexation de texte intégral et l'interrogation des colonnes
char, varchar et text.
Améliorations des requêtes pour la recherche de texte intégral
La syntaxe de requête de texte intégral de SQL Server 2005 pour les clauses CONTAINS,
CONTAINSTABLE, FREETEXT et FREETEXTTABLE prend en charge un nouveau
paramètre <lcid> qui peut être utilisé pour remplacer la langue du texte intégral de la colonne
par défaut par une langue du niveau de la clause. Cette langue au niveau de la clause indique
la liste de séparateurs de mots, analyseurs morphologiques, synonymes et mots parasites à
utiliser pour tous les termes de la requête de texte intégral. Le LCID est spécifié soit sous la
forme d'une valeur numérique soit sous la forme d'une chaîne. La valeur du paramètre <lcid>
LANGUAGE peut également être spécifiée comme une variable Transact-Sql si elle est
utilisée dans une clause de requête de texte intégral dans une procédure stockée.
Vous pouvez par exemple transmettre la chaîne de recherche et la valeur de langue au niveau
la requête en tant que paramètre pour une procédure stockée qui obtient la chaîne de recherche
à partir d'un champ de saisie de texte et la langue de la requête à partir d'une liste des langues
prises en charge.
Pour obtenir un exemple de code illustrant l'utilisation du paramètre LCID, consultez l'article
Recherche de texte intégral de SQL Server 2005 : données internes et améliorations dans la
bibliothèque MSDN. Pour plus d'informations sur la manière d'utiliser le paramètre LCID
dans les requêtes de texte intégral, consultez les sections FREETEXT (Transact-SQL),
FREETEXTTABLE (Transact-SQL), CONTAINS (Transact-SQL) ou CONTAINSTABLE
(Transact-SQL) dans la documentation en ligne de SQL Server 2005.
Dans les versions antérieures, le mappage de DocIds vers des valeurs-clés de texte intégral se
faisait dans le moteur de texte intégral. Dans SQL Server 2005, ce processus a été déplacé
vers le moteur de base de données où des stratégies de mise en cache plus efficaces et
cohérentes peuvent être utilisées. Cette migration, en plus des améliorations du moteur de
requête, devrait accélérer les requêtes de texte intégral par rapport aux versions antérieures.
Recherche de texte intégral de données XML
SQL Server 2005 présente un nouveau type de données xml qui vous autorise à stocker un
fragment ou document XML. La recherche de texte intégral dans SQL Server prend
maintenant en charge la création d'index de texte intégral sur et les requêtes de texte intégral
par rapport dans les données stockées dans le type de données xml.
Les requêtes ont la granularité de la valeur de colonne. Les prédicats de texte intégral émis par
rapport à une colonne XML indexée en texte intégral renvoient des lignes où la chaîne de
recherche spécifiée existe n'importe où dans le contenu de la colonne. Pour plus
d'informations, consultez la section Interrogation des colonnes varbinary (max) et xml dans la
documentation en ligne de SQL Server 2005.
Interaction avec d'autres produits de bases de données
Lorsque vous travaillez avec autres systèmes de base de données, la tâche la plus importante
pour les applications internationales consiste à déterminer la page de code et les règles de ce
système. Un grand nombre des méthodes d'accès aux données pour SQL Server utilisent
COM et par là-même des données Unicode. SQL Native Client utilise également Unicode. Par
conséquent, le niveau de prise en charge d'Unicode par les autres produits de bases de
données est l'information principale dont vous avez besoin pour déterminer comment une
application internationale s'exécutera entre eux.
Par exemple, d'autres produits de bases de données tels qu'Oracle et Sybase SQL Server
prennent en charge Unicode par le biais de l'encodage UTF-8. D'habitude, ceci ne vous affecte
pas parce que les données doivent être converties en UTF-16 à l'aide d'ADO/OLE DB avant
que vous voyiez les informations. Vous devez cependant être conscient de cette différence, si
vous essayez d'interagir directement avec les données dans de tels produits.
Certains produits prennent en charge les types de données de caractère National, mais ne les
traitent pas comme des types de données Unicode. Pour de telles bases de données, nchar et
nvarchar sont des champs que vous pourriez utiliser pour stocker des données japonaises
dans une base de données anglaise (États-Unis). L'utilisation des types de données de
caractères National pour spécifier du texte Unicode est spécifique à Microsoft SQL Server.
Donc, si vous utilisez des commandes telles que OPENROWSET, si vous exécutez des
requêtes sur un autre produit ou si vous importez des données depuis d'autres systèmes, il est
très important que vous sachiez comment les informations de texte internationales sont gérées
dans l'autre base de données. Pour plus d'informations, consultez les sections Connexion au
moteur de base de données SQL Server et Requêtes distribuées dans la documentation en
ligne de SQL Server 2005.
Pour des informations sur la connexion à des sources de données externes dans
SQL Server 2005 pour le développement d'applications, consultez les sections suivantes dans
la documentation en ligne de SQL Server 2005 :
SQL Server Analysis Services (SSAS)
SQL Server Integration Services (SSIS)
SQL Server Reporting Services
Réplication de SQL Server
Présentation du pilote JDBC
Utilisation des sources de données (Analysis
Services)
Connexions d'Integration Services
Sources de données prises en charge par
Reporting Services
Réplication de base de données hétérogène
Accès aux données à partir d'objets de base de
données CLR
Conclusion
Microsoft SQL Server 2005 s'appuie sur la puissante série de fonctions internationales qui
étaient fournies dans SQL Server 2000 et ajoute une prise en charge d'Unicode améliorée,
plus cohérente, ainsi que l'intégration avec les fonctionnalités multilingues du système
d'exploitation Windows et du service CLR (Common Language Runtime). SQL Server 2005
combine des bases solides pour la prise en charge de bases de données internationales avec
une grande variété d'outils de développement multilingues pour le développement rapide et le
déploiement robuste de solutions internationales pour la finance, le commerce électronique et
la communication globale.
Pour plus d'informations :
SQL Server Developer Center
Ce document vous a-t-il aidé ? Merci de nous faire part de vos commentaires. Sur une échelle
de 1 (médiocre) à 5 (excellent), comment jugez-vous ce document ?
Remerciements
Ce document a été écrit à l'origine par Michael Kaplan pour SQL Server 2000, avec
l'assistance de Michael Kung, responsable de programme pour SQL Server, Peter Carlin,
responsable du développement pour le moteur relationnel de SQL Server, et Fernando Caro,
responsable de programme international principal. Des informations supplémentaires ont été
fournies par Michael Rys, Euan Garden, Fadi Fakhouri, James Howey et Margaret Li. Les
informations sur la prise en charge des classements de SQL Server 7.0 et 2000 ont été
fournies par Julie Bennett, Cathy Wissink et John McConnell.
Les informations mises à jour sur les fonctionnalités de SQL Server 2005 ont été fournies par
l'équipe User Education de SQL Server, avec l'assistance de Fernando Caro et de Nobuhiko
Kishi.
Annexe A : Suffixes de classement
Suffixe
_BIN
_CI_AI
_CI_AI_WS
_CI_AI_KS
_CI_AI_KS_WS
_CI_AS
_CI_AS_WS
_CI_AS_KS
_CI_AS_KS_WS
_CS_AI
_CS_AI_WS
_CS_AI_KS
_CS_AI_KS_WS
Signification
Tri binaire
non sensible à la casse, non sensible aux accents, non sensible au type de
kana, non sensible à la largeur
non sensible à la casse, non sensible aux accents, non sensible au type de
kana, sensible à la largeur
non sensible à la casse, non sensible aux accents, sensible au type de
kana, non sensible à la largeur
non sensible à la casse, non sensible aux accents, sensible au type de
kana, sensible à la largeur
non sensible à la casse, sensible aux accents, non sensible au type de
kana, non sensible à la largeur
non sensible à la casse, sensible aux accents, non sensible au type de
kana, sensible à la largeur
non sensible à la casse, sensible aux accents, sensible au type de kana,
non sensible à la largeur
non sensible à la casse, sensible aux accents, sensible au type de kana,
sensible à la largeur
sensible à la casse, non sensible aux accents, non sensible au type de
kana, non sensible à la largeur
sensible à la casse, non sensible aux accents, non sensible au type de
kana, sensible à la largeur
sensible à la casse, non sensible aux accents, sensible au type de kana,
non sensible à la largeur
sensible à la casse, non sensible aux accents, sensible au type de kana,
sensible à la largeur
_CS_AS
sensible à la casse, sensible aux accents, non sensible au type de kana,
non sensible à la largeur
_CS_AS_WS
sensible à la casse, sensible aux accents, non sensible au type de kana,
sensible à la largeur
_CS_AS_KS
sensible à la casse, sensible aux accents, sensible au type de kana, non
sensible à la largeur
_CS_AS_KS_WS sensible à la casse, sensible aux accents, sensible au type de kana,
sensible à la largeur
Remarque : La sensibilité au kana est définie par défaut sur non sensible. En d'autres
termes, par défaut, katakana et hiragana sont traités de la même façon. La sensibilité à la
largeur est également réglée sur non sensible par défaut. En d'autres termes, par défaut, les
caractères de pleine chasse et demi-chasse sont traités de la même façon.
Annexe B : Paramètres régionaux pris en charge dans
Windows
Anglais (us_english)
Allemand (Deutsch)
Français (Français)
Japonais (“ú–{Œê)
Danois (Dansk)
Espagnol (Español)
Italien (Italiano)
Néerlandais (Nederlands)
Norvégien (Norsk)
Portugais (Português)
Finnois (Suomi)
Suédois (Svenska)
Tchèque (èeština)
Hongrois (magyar)
Polonais (polski)
Roumain (românã)
Croate (hrvatski)
Slovaque (slovenèina)
Slovène (slovenski)
Grec (åëëçíéêÜ)
Bulgare (áúëãàðñêè)
Russe (ðóññêèé)
Turc (Türkçe)
Anglais britannique (British)
Estonien (eesti)
Letton (latviešu)
Lituanien (lietuviø)
Brésilien (Português - Brasil)
Chinois traditionnel (ÁcÅ餤¤å)
Coréen (çѱ¹¾î)
Chinois simplifié (?‘Ì’†•¶)
Arabe (Arabic)
Thaïlandais (ä·Â)
Annexe C : Ordres de tri spécifiques à SQL
Des ordres de tri spécifiques à SQL sont également inclus dans SQL Server 2005. Ces ordres
de tri spécifiques à SQL sont illustrés dans le tableau suivant. Un grand nombre d'entre eux
prennent en charge certaines des diverses parties des suffixes décrits précédemment, mais tous
les suffixes ne sont pas pris en charge.
SQL_1xCompat_CP850
SQL_Estonian_CP1257
SQL_Latin1_General_Pref_CP4
SQL_AltDiction_CP1253
SQL_Hungarian_CP1250
SQL_AltDiction_CP850
SQL_AltDiction_Pref_CP8
50
SQL_Croatian_CP1250
SQL_Czech_CP1250
SQL_Danish_Pref_CP1
SQL_EBCDIC037_CP1
SQL_EBCDIC273_CP1
SQL_Icelandic_Pref_CP1
SQL_Latin1_General_CP1
SQL_EBCDIC277_CP1
SQL_EBCDIC278_CP1
SQL_EBCDIC280_CP1
SQL_EBCDIC284_CP1
SQL_EBCDIC285_CP1
SQL_AltDiction_CP1253
37
SQL_Latin1_General_Pref_CP8
50
SQL_Latvian_CP1257
SQL_Lithuanian_CP1257
SQL_Latin1_General_CP1250 SQL_MixDiction_CP1253
SQL_Latin1_General_CP1251 SQL_Polish_CP1250
SQL_Latin1_General_CP1253 SQL_Romanian_CP1250
SQL_Latin1_General_CP1254 SQL_Scandinavian_CP850
SQL_Latin1_General_CP
SQL_Scandinavian_Pref_CP850
1255
SQL_Latin1_General_CP1256 SQL_Slovak_CP1250
SQL_Latin1_General_CP1257 SQL_Slovenian_CP1250
SQL_Latin1_General_CP437 SQL_SwedishPhone_Pref_CP1
SQL_Latin1_General_CP850 SQL_SwedishStd_Pref_CP1
SQL_Latin1_General_Pref_C SQL_Ukrainian_CP1251
P1
SQL_Hungarian_CP1250
SQL_Latin1_General_Pref_CP8
50
Annexe D : Langues prises en charge dans
SQL Server 2005
Vous pouvez afficher cette même liste dans SQL Server 2005 en exécutant cette instruction :
select langid, alias, lcid, msglangid from sys.syslanguages
Nom en français
Anglais
Allemand
Français
Japanese
Danois
Espagnol
Italien
Néerlandais
Norvégien
Portugais
Finnois
Suédois
Tchèque
Hongrois
Windows LCID
1033
1031
1036
1041
1030
3082
1040
1043
2068
2070
1035
1053
1029
1038
ID de message
1033
1031
1036
1041
1030
3082
1040
1043
2068
2070
1035
1053
1029
1038
Polonais
Roumain
Croate
Slovaque
Slovène
Grec
Bulgare
Russe
Turc
Anglais britannique
Estonien
Letton
Lituanien
Brésilien
Chinois traditionnel
Korean
Chinois simplifié
Arabe
Thaï
1045
1048
1050
1051
1060
1032
1026
1049
1055
2057
1061
1062
1063
1046
1028
1042
2052
1025
1054
1045
1048
1050
1051
1060
1032
1026
1049
1055
1033
1061
1062
1063
1046
1028
1042
2052
1025
1054
Annexe E : Langues de texte intégral ajoutées dans
SQL Server 2005
Cette liste est disponible également dans la section Considérations internationales pour la
recherche de texte intégral dans la documentation en ligne de SQL Server 2005. Pour une liste
complète des langues disponibles pour l'indexation et les opérations de requêtes de texte
intégral, utilisez sys.fulltext_langages.
Identificateur des paramètres régionaux de
classement Unicode
Chinois bopomofo (Taïwan)
Ponctuation chinoise
Nombre de traits chinois
Nombre de traits chinois (Taïwan)
Néerlandais
Anglais (Royaume-Uni)
Français
Unicode général
Allemand
Annuaire allemand
Italien
Japanese
Langue pour le stockage des données de
texte intégral
Chinois traditionnel
Chinois simplifié
Chinois simplifié
Chinois traditionnel
Néerlandais
Anglais (Royaume-Uni)
Français
Anglais (États-Unis)
Allemand
Allemand
Italien
Japanese
Unicode japonais
Korean
Unicode coréen
Espagnol (Espagne)
Suédois/finlandais
Japanese
Korean
Korean
Espagnol
Suédois
Annexe F : Classements mis à jour dans SQL Server 2005
Cette liste est également disponible dans la section Paramètres de classement dans
l'installation dans la documentation en ligne de SQL Server 2005. Pour une liste complète des
classements pris en charge dans une instance de SQL Server 2005, utilisez l'instruction
fn_helpcollations ().
Ancien nom de classement
Japanese
Chinese
Nouveau nom de classement
Japanese_90
Chinese_PRC_90
Chinese_PRC_Stroke
Chinese_PRC_Stroke_90
Chinese_Taiwan_Bopomofo
Chinese_Taiwan_Bopomofo_90
Chinese_Taiwan_Stroke
Korean
Hindi
Indic
Chinese_Taiwan_Stroke_90
Korean_90
(désapprouvé dans cette version)
General_90