

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Analyse de l'architecture et de la configuration de Babelfish
<a name="babelfish-understanding-overview-howitworks"></a>

Vous gérez le cluster de bases de données Aurora PostgreSQL-Compatible Edition exécutant Babelfish comme n'importe quel cluster de bases de données Aurora. En d'autres termes, vous bénéficiez de la capacité de mise à l'échelle, de la haute disponibilité avec prise en charge du basculement et de la réplication intégrée d'un cluster de bases de données Aurora. Pour en savoir plus sur ces fonctionnalités, consultez [Gestion des performances et dimensionnement des clusters de bases de données Aurora](Aurora.Managing.Performance.md), [Haute disponibilité pour Amazon Aurora](Concepts.AuroraHighAvailability.md) et [Réplication avec Amazon Aurora](Aurora.Replication.md). Vous avez également accès à de nombreux autres outils et utilitaires AWS, y compris les suivants :
+ Amazon CloudWatch est un service de surveillance et d'observabilité qui vous fournit des données et des informations exploitables. Pour de plus amples informations, consultez [Surveillance des métriques (Amazon Aurora) avec Amazon CloudWatch](monitoring-cloudwatch.md).
+ Performance Insights est une fonction de réglage et de surveillance des performances de la base de données qui vous aide à évaluer rapidement la charge sur votre base de données. Pour en savoir plus, veuillez consulter la section [Surveillance de la charge de la base de données avec Performance Insights sur ](USER_PerfInsights.md).
+ Les bases de données globales Aurora couvrent plusieurs Régions AWS, permettant des lectures globales à faible latence, et assurent une reprise rapide de toute interruption susceptible d'affecter une Région AWS entière. Pour de plus amples informations, consultez [Utilisation d’Amazon Aurora Global Database](aurora-global-database.md).
+ L'application automatique de correctifs logiciels maintient votre base de données à jour avec les derniers correctifs de sécurité et de fonctions dès qu'ils sont disponibles.
+ Les événements Amazon RDS vous informent par e-mail ou par SMS des événements importants relatifs à la base de données, comme les basculements automatiques. Pour de plus amples informations, consultez [Surveillance des événements Amazon Aurora](working-with-events.md). 

Vous trouverez ci-dessous des informations sur l'architecture de Babelfish et sur la façon dont les bases de données SQL Server que vous migrez sont gérées par Babelfish. Lorsque vous créez votre cluster de bases de données Babelfish, vous devez prendre des décisions à l'avance concernant une base de données unique ou plusieurs bases de données, les classements et d'autres détails. 

**Topics**
+ [Architecture Babelfish](babelfish-architecture.md)
+ [Paramètres du groupe de paramètres de cluster de bases de données pour Babelfish](babelfish-configuration.md)
+ [Comprendre les classements dans Babelfish pour Aurora PostgreSQL.](babelfish-collations.md)
+ [Gestion du traitement des erreurs Babelfish avec des trappes de secours](babelfish-strict.md)

# Architecture Babelfish
<a name="babelfish-architecture"></a>

Lorsque vous créez un cluster Aurora PostgreSQL dans lequel Babelfish est activé, Aurora approvisionne ce cluster avec une base de données PostgreSQL nommée `babelfish_db`. Cette base de données héberge l'ensemble des objets et structures SQL Server migrés. 

**Note**  
Dans un cluster Aurora PostgreSQL, le nom de base de données `babelfish_db` est réservé à Babelfish. La création de votre propre base de données « babelfish\$1db » sur un cluster de bases de données Babelfish empêche Aurora d'allouer Babelfish. 

Lorsque vous vous connectez au port TDS, la session est placée dans la base de données `babelfish_db`. Depuis T-SQL, la structure ressemble à celle d'une connexion à une instance SQL Server. Vous pouvez consulter les bases de données `master`, `msdb` et `tempdb` ainsi que le catalogue `sys.databases`. Vous pouvez créer des bases de données utilisateur supplémentaires et passer d'une base de données à l'autre à l'aide de l'instruction USE. Lorsque vous créez une base de données utilisateur SQL Server, celle-ci est mise à plat dans la base de données PostgreSQL `babelfish_db`. Votre base de données conserve une syntaxe et une sémantique inter-bases de données identiques ou semblables à celles fournies par SQL Server.

## Utilisation de Babelfish avec une ou plusieurs bases de données
<a name="babelfish-single_vs_multi_db"></a>

Lorsque vous créez un cluster Aurora PostgreSQL à utiliser avec Babelfish, vous pouvez choisir d'utiliser une base de données SQL Server individuellement ou plusieurs bases de données SQL Server ensemble. Votre choix détermine la façon dont les noms des schémas SQL Server contenus dans la base de données `babelfish_db` apparaissent à partir d'Aurora PostgreSQL. Le mode de migration est stocké dans le paramètre `migration_mode`. Vous ne devez pas modifier ce paramètre après avoir créé votre cluster car vous pourriez perdre l'accès à tous vos objets SQL précédemment créés.

En mode single-db, les noms des schémas de la base de données SQL Server restent les mêmes dans la base de données `babelfish_db` de PostgreSQL. Si vous choisissez de ne migrer qu'une seule base de données, les noms de schémas de la base de données utilisateur migrée peuvent être référencés dans PostgreSQL avec les mêmes noms que ceux utilisés dans SQL Server. Par exemple, les schémas `dbo` et `smith` résident dans la base de données `dbA`*.* 

![\[\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/babelfish_single_db_mode.png)


Lorsque vous vous connectez via TDS, vous pouvez exécuter `USE dba` pour voir les schémas `dbo` et `dev` depuis T-SQL, comme vous le feriez dans SQL Server. Les noms de schémas inchangés sont également visibles depuis PostgreSQL.

En mode à plusieurs bases de données, les noms de schémas des bases de données utilisateur deviennent `dbname_schemaname` lorsqu'ils font l'objet d'un accès depuis PostgreSQL. Les noms de schémas restent les mêmes lorsqu'ils font l'objet d'un accès depuis T-SQL.

![\[\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/babelfish_multi_db_mode.png)


Comme le montre l'image, le mode à une base de données et le mode à plusieurs bases de données sont identiques à la procédure de connexion via le port TDS et d'utilisation de T-SQL dans SQL Server. Par exemple, `USE dbA` répertorie les schémas `dbo` et `dev` comme dans SQL Server. Les noms de schémas mappés, tels que `dba_dbo` et `dba_dev`, sont visibles depuis PostgreSQL.

Vos schémas sont toujours contenus dans chacune des bases de données. Le nom de chaque base de données précède le nom du schéma SQL Server, avec un trait de soulignement comme délimiteur. Par exemple :
+ `dba` contient `dba_dbo` et `dba_dev`.
+ `dbb` contient `dbb_dbo` et `dbb_test`.
+ `dbc` contient `dbc_dbo` et `dbc_prod`.

Dans la base de données `babelfish_db`, l'utilisateur T-SQL doit toujours exécuter `USE dbname` pour modifier le contexte de la base de données, afin que la présentation reste semblable à celle de SQL Server.

## Choix d'un mode de migration
<a name="babelfish-choosing_single_vs_multi"></a>

Chaque mode de migration présente des avantages et des inconvénients. Choisissez votre mode de migration en fonction du nombre de bases de données utilisateur dont vous disposez et de vos plans de migration. Après avoir créé un cluster à utiliser avec Babelfish, vous ne devez pas changer le mode de migration car vous pourriez perdre l'accès à tous vos objets SQL précédemment créés. Lorsque vous choisissez un mode de migration, tenez compte des exigences de vos bases de données utilisateur et de vos clients.

Lorsque vous créez un cluster à utiliser avec Babelfish, Aurora PostgreSQL crée les bases de données système, `master` et `tempdb`. Si vous avez créé ou modifié des objets dans les bases de données système (`master` ou `tempdb`), veillez à recréer ces objets dans votre nouveau cluster. Contrairement à SQL Server, Babelfish ne se réinitialise pas `tempdb` après le redémarrage d'un cluster.

Utilisez le mode de migration d'une base de données individuelle dans les cas suivants :
+ Si vous migrez une base de données SQL Server individuelle. En mode Base de données individuelle, les noms des schémas migrés, lorsqu'ils font l'objet d'un accès depuis PostgreSQL, sont identiques aux noms des schémas SQL Server d'origine. Cela permet de réduire les modifications de code apportées aux requêtes SQL existantes si vous souhaitez les optimiser pour les exécuter avec une connexion PostgreSQL.
+ Si votre objectif final est une migration complète vers l'instance native d'Aurora PostgreSQL. Avant toute migration, regroupez vos schémas en un seul (`dbo`), puis procédez à une migration vers un seul cluster pour limiter les modifications nécessaires.

Utilisez le mode de migration de plusieurs bases de données dans les cas suivants :
+ Si vous souhaitez bénéficier de l'expérience SQL Server par défaut avec plusieurs bases de données utilisateur dans la même instance.
+ Si plusieurs bases de données utilisateur doivent être migrées ensemble.

# Paramètres du groupe de paramètres de cluster de bases de données pour Babelfish
<a name="babelfish-configuration"></a>

Lorsque vous créez un cluster de bases de données Aurora PostgreSQL et choisissez **Turn on Babelfish** (Activer Babelfish), un groupe de paramètres de cluster de bases de données est créé automatiquement pour vous si vous choisissez **Create new** (Créer un nouveau). Ce groupe de paramètres de cluster de bases de données est basé sur le groupe de paramètres de cluster de bases de données Aurora PostgreSQL pour la version d’Aurora PostgreSQL choisie pour l’installation, par exemple Aurora PostgreSQL version 14. Il est nommé en utilisant le modèle général suivant : 

```
custom-aurora-postgresql14-babelfish-compat-3
```

Vous pouvez modifier les paramètres suivants pendant le processus de création du cluster, mais certains d’entre eux ne peuvent pas être modifiés une fois qu’ils sont stockés dans le groupe de paramètres personnalisés. Choisissez donc soigneusement :
+ Base de données unique ou plusieurs bases de données
+ Paramètres régionaux de classement par défaut
+ Nom du classement
+ Groupe de paramètres de base de données

Pour utiliser un cluster de bases de données Aurora PostgreSQL version 13 ou un groupe de paramètres ultérieur, modifiez le groupe et définissez le paramètre `babelfish_status` sur `on`. Spécifiez toutes les options Babelfish avant de créer votre cluster Aurora PostgreSQL. Pour en savoir plus, consultez [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md).

Les paramètres suivants contrôlent les préférences Babelfish. Sauf indication contraire dans la description, les paramètres sont modifiables. La valeur par défaut est incluse dans la description. Pour voir les valeurs autorisées pour n’importe quel paramètre, procédez comme suit : 

**Note**  
Lorsque vous associez un nouveau groupe de paramètres de base de données à une instance de base de données, les paramètres statiques et dynamiques modifiés sont appliqués uniquement après que l’instance de base de données est redémarrée. Toutefois, si vous modifiez des paramètres dynamiques dans le groupe de paramètres de base de données après l’avoir associé à l’instance de base de données, ces modifications sont appliquées immédiatement sans redémarrage.

1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.

1. Choisissez **Parameter groups** (Groupes de paramètres) dans le menu de navigation.

1. Choisissez le groupe de paramètres du cluster de bases de données `default.aurora-postgresql14` dans la liste.

1. Saisissez le nom d’un paramètre dans le champ de recherche. Par exemple, saisissez `babelfishpg_tsql.default_locale` dans le champ de recherche pour afficher ce paramètre ainsi que sa valeur par défaut et ses valeurs autorisées. 
**Note**  
Les bases de données globales Babelfish pour Aurora PostgreSQL ne fonctionnent dans les régions secondaires que si les paramètres suivants sont activés dans ces régions.


| Paramètre | Description | Type d’application | Modifiable | 
| --- | --- | --- | --- | 
| babelfishpg\$1tsql.apg\$1enable\$1correlated\$1scalar\$1transform | Permet au planificateur de transformer une sous-requête scalaire corrélée dans Babelfish. (Par défaut : on) (Autorisé : on, off)  | dynamic | true | 
| babelfishpg\$1tsql.apg\$1enable\$1subquery\$1cache | Active l’utilisation du cache pour les sous-requêtes scalaires corrélées dans Babelfish. (Par défaut : on) (Autorisé : on, off)  | dynamic | true | 
| babelfishpg\$1tds.tds\$1default\$1numeric\$1scale | Définit l’échelle par défaut du type numérique à envoyer dans les métadonnées de la colonne TDS si le moteur n’en spécifie pas. (Par défaut : 8) (Autorisée : 0 à 38)  | dynamic | true | 
| babelfishpg\$1tds.tds\$1default\$1numeric\$1precision | Entier qui définit la précision par défaut du type numérique à envoyer dans les métadonnées de la colonne TDS si le moteur n’en spécifie pas. (Par défaut : 38) (Autorisée : 1 à 38) | dynamic | true | 
| babelfishpg\$1tds.tds\$1default\$1packet\$1size | Entier qui définit la taille par défaut des paquets pour la connexion des clients SQL Server. (Par défaut : 4 096) (Autorisée : 512 à 32 767) | dynamic | true | 
| babelfishpg\$1tds.tds\$1default\$1protocol\$1version | Entier qui définit une version de protocole TDS par défaut pour la connexion des clients. (Par défaut : DEFAULT) (Autorisé : TDSv7 .0, TDSv7 .1, TDSv7 .1.1, TDSv7 .2, TDSv7 .3A, TDSv7 .3B, .4, DEFAULT) TDSv7 | dynamic | true | 
| babelfishpg\$1tds.default\$1server\$1name | Chaîne qui identifie le nom par défaut du serveur Babelfish. (Par défaut : Microsoft SQL Server) (Autorisée : null) | dynamic | true | 
| babelfishpg\$1tds.tds\$1debug\$1log\$1level | Entier qui définit le niveau de journalisation dans TDS ; 0 désactive la journalisation. (Par défaut : 1) (Autorisée : 0, 1, 2, 3) | dynamic | true | 
| babelfishpg\$1tds.listen\$1addresses | Chaîne qui définit le nom d’hôte ou les adresses IP sur lesquelles écouter TDS. Ce paramètre ne peut pas être modifié une fois que le cluster de bases de données Babelfish a été créé. (Par défaut : \$1 ) (Autorisée : null)  | – | false | 
| babelfishpg\$1tds.port | Entier qui spécifie le port TCP utilisé pour les requêtes dans la syntaxe SQL Server. (Par défaut : 1 433) (Autorisée : 1 à 65 535) | statique | true | 
| babelfishpg\$1tds.tds\$1ssl\$1encrypt | Booléen qui active (0) ou désactive (1) le chiffrement des données traversant le port d’écoute TDS. Pour obtenir des informations détaillées sur l’utilisation de SSL pour les connexions client, consultez [Paramètres SSL Babelfish et connexions client](#babelfish-ssl). (Par défaut : 0) (Autorisée : 0, 1) | dynamic | true | 
| babelfishpg\$1tds.tds\$1ssl\$1max\$1protocol\$1version | Chaîne qui indique la version de SSL/TLS protocole la plus élevée à utiliser pour la session TDS. (Par défaut : 'TLSv1.2') (Autorisé :' ',' TLSv1 TLSv1 .1', '.2') TLSv1 | dynamic | true | 
| babelfishpg\$1tds.tds\$1ssl\$1min\$1protocol\$1version | Chaîne qui indique la version minimale SSL/TLS du protocole à utiliser pour la session TDS. (Par défaut : « TLSv1 .2 » pour Aurora PostgreSQL version 16, « » TLSv1 pour les versions antérieures à Aurora PostgreSQL version 16) (Autorisé : « », « .1', « .2') TLSv1 TLSv1 TLSv1 | dynamic | true | 
| babelfishpg\$1tds.unix\$1socket\$1directories | Chaîne qui identifie le répertoire des sockets Unix du serveur TDS. Ce paramètre ne peut pas être modifié une fois que le cluster de bases de données Babelfish a été créé. (Par défaut : /tmp) (Autorisée : null) | – | false | 
| babelfishpg\$1tds.unix\$1socket\$1group | Chaîne qui identifie le groupe de sockets Unix du serveur TDS. Ce paramètre ne peut pas être modifié une fois que le cluster de bases de données Babelfish a été créé. (Par défaut : rdsdb) (Autorisée : null) | – | false | 
| babelfishpg\$1tsql.default\$1locale |  Chaîne qui spécifie les paramètres régionaux par défaut utilisés pour les classements Babelfish. Les paramètres régionaux par défaut se limitent aux paramètres régionaux ; ils n’incluent aucun qualificatif. Définissez ce paramètre au moment de l’approvisionnement d’un cluster de bases de données Babelfish. Une fois le cluster de bases de données approvisionné, les modifications apportées à ce paramètre sont ignorées. (Par défaut : en\$1US) (Autorisée : voir [tables](babelfish-collations.md))   | statique | true | 
| babelfishpg\$1tsql.migration\$1mode |  Liste non modifiable qui spécifie la prise en charge des bases de données utilisateur uniques ou multiples. Définissez ce paramètre au moment de l’approvisionnement d’un cluster de bases de données Babelfish. Une fois le cluster de bases de données approvisionné, vous ne pouvez pas modifier la valeur de ce paramètre. (Par défaut : multi-db à partir d’Aurora PostgreSQL version 16, single-db pour les versions antérieures à Aurora PostgreSQL version 16) (Autorisé : single-db, multi-db, null)  | statique | true | 
| babelfishpg\$1tsql.server\$1collation\$1name |  Chaîne qui spécifie le nom du classement utilisé pour les actions au niveau du serveur. Définissez ce paramètre au moment de l’approvisionnement d’un cluster de bases de données Babelfish. Une fois le cluster de bases de données approvisionné, ne modifiez pas la valeur de ce paramètre. (Par défaut : bbf\$1unicode\$1general\$1ci\$1as) (Autorisée : voir [tables](babelfish-collations.md))  | statique | true | 
| babelfishpg\$1tsql.version |  Chaîne qui définit la sortie de la variable @@VERSION. Ne modifiez pas cette valeur pour les clusters de bases de données Aurora PostgreSQL. (Par défaut : null) (Autorisée : default)  | dynamic | true | 
| rds.babelfish\$1status | Chaîne qui définit l’état de la fonctionnalité Babelfish. Lorsque ce paramètre est défini sur `datatypesonly`, Babelfish est désactivé, mais les types de données SQL Server sont toujours disponibles. (Par défaut : off) (Autorisée : on, off, datatypesonly) | statique | true | 
| unix\$1socket\$1permissions | Entier qui définit les autorisations des sockets Unix du serveur TDS. Ce paramètre ne peut pas être modifié une fois que le cluster de bases de données Babelfish a été créé. (Par défaut : 0700) (Autorisée : 0 à 511) | – | false | 

## Paramètres SSL Babelfish et connexions client
<a name="babelfish-ssl"></a>

Pour exiger des SSL/TLS connexions à votre cluster de base de données Babelfish for Aurora PostgreSQL, utilisez le paramètre. `rds.force_ssl`
+ Pour exiger SSL/TLS des connexions, définissez la valeur du `rds.force_ssl` paramètre sur 1 (activé).
+ Pour désactiver SSL/TLS les connexions requises, définissez la valeur du `rds.force_ssl` paramètre sur 0 (désactivé).

La valeur par défaut de ce paramètre dépend de la version d’Aurora PostgreSQL :
+ Pour Aurora PostgreSQL 17 et les versions ultérieures : la valeur par défaut est 1 (activé).
+ Pour Aurora PostgreSQL 16 et les versions antérieures : la valeur par défaut est 0 (désactivé).

**Note**  
Lorsque vous effectuez une mise à niveau de version majeure d’Aurora PostgreSQL 16 ou version antérieure vers la version 17 ou une version ultérieure, la valeur par défaut du paramètre passe de 0 (désactivé) à 1 (activé). Ce changement peut entraîner des défaillances de connectivité pour les applications qui ne sont pas configurées pour le protocole SSL. Pour revenir au comportement par défaut précédent, définissez ce paramètre sur 0 (désactivé).

Pour des informations spécifiques au pilote, consultez [Connexion à un cluster de bases de données Babelfish](babelfish-connect.md).

Lorsqu’un client se connecte au port TDS (`1433` par défaut), Babelfish compare le paramètre SSL (Secure Sockets Layer) envoyé lors de l’établissement de la liaison client avec le paramètre Babelfish SSL (`tds_ssl_encrypt`). Babelfish détermine alors si une connexion est autorisée. Si une connexion est autorisée, le comportement de chiffrement est appliqué ou non, en fonction de vos paramètres et de la prise en charge du chiffrement offerte par le client.

Le tableau suivant montre comment Babelfish se comporte pour chaque combinaison.


| Paramètre SSL du client | Paramètre SSL de Babelfish | rds.force\$1ssl | Connexion autorisée ? | Valeur renvoyée au client | 
| --- | --- | --- | --- | --- | 
| ENCRYPT\$1ON | N’importe quel compte | N’importe quel compte | Autorisée, la connexion est intégralement chiffrée | ENCRYPT\$1ON | 
| ENCRYPT\$1OFF | tds\$1ssl\$1encrypt=1 | N’importe quel compte | Autorisée, la connexion est intégralement chiffrée | ENCRYPT\$1REQ | 
| ENCRYPT\$1OFF | tds\$1ssl\$1encrypt=0 | rds.force\$1ssl=0 | Autorisée, le paquet de connexion est chiffré | ENCRYPT\$1OFF | 
| ENCRYPT\$1OFF | tds\$1ssl\$1encrypt=0 | rds.force\$1ssl=1 | Non, connexion fermée | ENCRYPT\$1OFF | 
| ENCRYPT\$1NOT\$1SUP | tds\$1ssl\$1encrypt=0 | rds.force\$1ssl=0 | Oui | ENCRYPT\$1NOT\$1SUP | 
| ENCRYPT\$1NOT\$1SUP | tds\$1ssl\$1encrypt=1 | N’importe quel compte | Non, connexion fermée  | ENCRYPT\$1REQ | 
| ENCRYPT\$1NOT\$1SUP | tds\$1ssl\$1encrypt=0 | rds.force\$1ssl=1 | Non, connexion fermée | ENCRYPT\$1NOT\$1SUP | 
| ENCRYPT\$1CLIENT\$1CERT | N’importe quel compte | N’importe quel compte | Non, connexion fermée | Non pris en charge | 

# Comprendre les classements dans Babelfish pour Aurora PostgreSQL.
<a name="babelfish-collations"></a>

Lorsque vous créez un cluster de bases de données Aurora PostgreSQL avec Babelfish, vous choisissez un classement pour vos données. Un *classement* spécifie l’ordre de tri et les modèles de bits qui génèrent le texte ou les caractères dans un langage humain écrit donné. Un classement inclut des règles de comparaison des données pour un ensemble donné de modèles de bits. Le classement est lié à la localisation. Les différents paramètres régionaux affectent le mappage des caractères, l’ordre de tri, etc. Les attributs de classement sont reflétés dans les noms des différents classements. Pour plus d’informations sur les attributs, consultez [Babelfish collation attributes table](#bfish-collation-attributes-table). 

Babelfish mappe les classements SQL Server à des classements comparables fournis par Babelfish. Babelfish prédéfinit les classements Unicode avec des comparaisons de chaînes et des ordres de tri sensibles aux particularités culturelles. Babelfish permet également de traduire les classements de votre base de données SQL Server vers le classement Babelfish le plus proche. Des classements spécifiques aux paramètres régionaux sont fournis pour différentes langues et régions. 

Certains classements spécifient une page de code correspondant à un encodage côté client. Babelfish traduit automatiquement l’encodage du serveur vers l’encodage du client en fonction du classement de chaque colonne de sortie. 

Babelfish prend en charge les classements répertoriés dans [Babelfish supported collations table](#bfish-collations-table). Babelfish mappe les classements SQL Server à des classements comparables fournis par Babelfish. 

Babelfish utilise la version 153.80 de la bibliothèque de classements ICU (International Components for Unicode. Pour plus d’informations sur les classements ICU, consultez [Collation](https://unicode-org.github.io/icu/userguide/collation/) (Classement) dans la documentation ICU. Pour en savoir plus sur PostgreSQL et le classement, consultez [Collation Support](https://www.postgresql.org/docs/current/collation.html) (Prise en charge des classements) dans la documentation PostgreSQL.

**Topics**
+ [Paramètres de cluster de bases de données qui contrôlent le classement et les paramètres régionaux](#babelfish-collations.parameters)
+ [Classements déterministes et non déterministes dans Babelfish](#babelfish-collations.deterministic-nondeterministic)
+ [Classements pris en charge au niveau de la base de données dans Babelfish](#babelfish-collations.database-level)
+ [Classements de serveur et d’objet dans Babelfish](#babelfish-collations.reference-tables-supported-collations)
+ [Comportement de classement par défaut dans Babelfish](#babelfish-collations-default)
+ [Gestion des classements](collation.managing.md)
+ [Limites et différences de comportement des classements](collation.limitations.md)

## Paramètres de cluster de bases de données qui contrôlent le classement et les paramètres régionaux
<a name="babelfish-collations.parameters"></a><a name="collation-related-parameters"></a>

Les paramètres suivants ont une incidence sur le comportement du classement. 

**babelfishpg\$1tsql.default\$1locale**  
Ce paramètre spécifie les paramètres régionaux par défaut utilisés par le classement. Ce paramètre est utilisé en combinaison avec les attributs répertoriés dans [Babelfish collation attributes table](#bfish-collation-attributes-table) pour personnaliser les classements liés à une langue et à une région spécifiques. La valeur par défaut de ce paramètre est `en-US`.  
Les paramètres régionaux par défaut s’appliquent à tous les noms de classement Babelfish commençant par « BBF » et à tous les classements SQL Server mappés à des classements Babelfish. La modification de la valeur de ce paramètre sur un cluster de bases de données Babelfish existant n’affecte pas les paramètres régionaux des classements existants. Pour obtenir la liste des classements, consultez [Babelfish supported collations table](#bfish-collations-table). 

**babelfishpg\$1tsql.server\$1collation\$1name**  
Ce paramètre spécifie le classement par défaut du serveur (instance de cluster de bases de données Aurora PostgreSQL) et de la base de données. La valeur par défaut est `sql_latin1_general_cp1_ci_as`. `server_collation_name` doit être un classement `CI_AS` car, dans T-SQL, le classement du serveur détermine la façon dont les identifiants sont comparés.  
Lorsque vous créez votre cluster de bases de données Babelfish, vous choisissez le **Collation name** (Nom du classement) dans la liste sélectionnable. Il s’agit notamment des classements répertoriés dans [Babelfish supported collations table](#bfish-collations-table). Ne modifiez pas `server_collation_name` après la création de la base de données Babelfish.

Les paramètres que vous choisissez lorsque vous créez votre cluster de bases de données Babelfish pour Aurora PostgreSQL sont stockés dans le groupe de paramètres de cluster de bases de données associé au cluster pour ces paramètres et définissent son comportement de classement.

## Classements déterministes et non déterministes dans Babelfish
<a name="babelfish-collations.deterministic-nondeterministic"></a>

Babelfish prend en charge les classements déterministes et non déterministes :
+ Un *classement déterministe* considère que les caractères dont les séquences d’octets sont identiques sont égaux. Cela signifie que `x` et `X` ne sont pas égaux dans un classement déterministe. Les classements déterministes peuvent être sensibles à la casse (CS) et sensibles aux accents (AS).
+ Un *classement non déterministe* ne nécessite pas de correspondance identique. Un classement non déterministe considère que `x` et `X` sont égaux. Les classements non déterministes sont insensibles à la casse (CI), insensibles aux accents (AI) ou les deux.

Le tableau suivant présente certaines différences de comportement entre Babelfish et PostgreSQL lorsque vous utilisez des classements non déterministes.


| Babelfish | PostgreSQL | 
| --- | --- | 
|  Prend en charge la clause LIKE pour les classements CI\$1AS.  |  Ne prend pas en charge la clause LIKE sur les classements non déterministes.  | 
|  Ne prend en charge la clause LIKE que sur les classements AI suivants issus de la version 4.2.0 de Babelfish : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/babelfish-collations.html)  |  Ne prend pas en charge la clause LIKE sur les classements non déterministes.  | 

Pour obtenir la liste des autres limites et différences de comportement pour Babelfish par rapport à SQL Server et PostgreSQL, consultez [Limites et différences de comportement des classements](collation.limitations.md). 

Babelfish et SQL Server suivent une convention de dénomination pour les classements qui décrivent les attributs de classement, comme indiqué dans le tableau suivant.<a name="bfish-collation-attributes-table"></a>


| Attribut | Description | 
| --- | --- | 
| AI | Insensible aux accents. | 
| AS | Sensibles aux accents. | 
| BIN2 | BIN2 exige que les données soient triées dans l’ordre des points de code. L’ordre des points de code Unicode suit le même ordre de caractères pour les encodages UTF-8, UTF-16 et UCS-2. L’ordre des points de code est un classement déterministe rapide. | 
| CI | Insensible à la casse. | 
| CS | Sensible à la casse | 
| PREF | Pour trier les majuscules avant les minuscules, utilisez un classement PREF. Si la comparaison est insensible à la casse, la version majuscule d’une lettre est triée avant la version minuscule, à condition qu’il n’y ait pas d’autre distinction. La bibliothèque ICU prend en charge les préférences pour les majuscules avec `colCaseFirst=upper`, mais pas pour les classements CI\$1AS. PREF ne peut être appliqué qu’aux classements déterministes `CS_AS`. | 

## Classements pris en charge au niveau de la base de données dans Babelfish
<a name="babelfish-collations.database-level"></a>

Les classements suivants sont pris en charge au niveau de la base de données dans Babelfish :
+ bbf\$1unicode\$1bin2
+ bbf\$1unicode\$1cp1\$1ci\$1ai
+ bbf\$1unicode\$1cp1\$1ci\$1as
+ bbf\$1unicode\$1cp1250\$1ci\$1ai
+ bbf\$1unicode\$1cp1250\$1ci\$1as
+ bbf\$1unicode\$1cp1257\$1ci\$1ai
+ bbf\$1unicode\$1cp1257\$1ci\$1as
+ estonian\$1ci\$1ai
+ estonian\$1ci\$1as
+ finnish\$1swedish\$1ci\$1ai
+ finnish\$1swedish\$1ci\$1as
+ french\$1ci\$1ai
+ french\$1ci\$1as
+ latin1\$1general\$1bin2
+ latin1\$1general\$1ci\$1ai
+ latin1\$1general\$1ci\$1as
+ latin1\$1general\$190\$1bin2
+ latin1\$1general\$1100\$1bin2
+ latin1\$1general\$1140\$1bin2
+ modern\$1spanish\$1ci\$1ai
+ modern\$1spanish\$1ci\$1as
+ polish\$1ci\$1ai
+ polish\$1ci\$1as
+ sql\$1latin1\$1general\$1cp1\$1ci\$1ai
+ sql\$1latin1\$1general\$1cp1\$1ci\$1as
+ sql\$1latin1\$1general\$1cp1250\$1ci\$1as
+ sql\$1latin1\$1general\$1cp1251\$1ci\$1as
+ sql\$1latin1\$1general\$1cp1257\$1ci\$1as
+ traditional\$1spanish\$1ci\$1ai
+ traditional\$1spanish\$1ci\$1as

**Note**  
Pour utiliser un classement différent au niveau de la base de données, assurez-vous qu’il correspond au classement au niveau du serveur. Pour plus d’informations, consultez [Classements de serveur et d’objet dans Babelfish](#babelfish-collations.reference-tables-supported-collations).

## Classements de serveur et d’objet dans Babelfish
<a name="babelfish-collations.reference-tables-supported-collations"></a>

Utilisez les classements suivants comme classement de serveur ou classement d’objet.<a name="bfish-collations-table"></a>


| ID du classement | Remarques | 
| --- | --- | 
|  bbf\$1unicode\$1general\$1ci\$1as  |  Prend en charge la comparaison insensible à la casse et l’opérateur LIKE.  | 
|  bbf\$1unicode\$1cp1\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt) également connu sous le nom de CP1252.  | 
|  bbf\$1unicode\$1CP1250\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1250.txt) permettant de représenter des textes dans les langues d’Europe centrale et d’Europe de l’Est qui utilisent l’alphabet latin.  | 
|  bbf\$1unicode\$1CP1251\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1251.txt) pour les langues utilisant l’alphabet cyrillique.  | 
|  bbf\$1unicode\$1cp1253\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1253.txt) utilisé pour représenter le grec moderne.  | 
|  bbf\$1unicode\$1cp1254\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1254.txt) qui prend en charge le turc.  | 
|  bbf\$1unicode\$1cp1255\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1255.txt) qui prend en charge l’hébreu.  | 
|  bbf\$1unicode\$1cp1256\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1256.txt) pour les langues utilisant l’alphabet arabe.  | 
|  bbf\$1unicode\$1cp1257\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1257.txt) permettant de prendre en charge les langues estonienne, lettone et lituanienne.  | 
|  bbf\$1unicode\$1cp1258\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1258.txt) utilisé pour les caractères vietnamiens.  | 
|  bbf\$1unicode\$1cp874\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit874.txt) utilisé pour les caractères thaïlandais.  | 
|  sql\$1latin1\$1general\$1cp1250\$1ci\$1as  |  [Encodage non déterministe de caractères sur un octet](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1250.txt) utilisé pour représenter les caractères latins.  | 
|  sql\$1latin1\$1general\$1cp1251\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1251.txt) prenant en charge les caractères latins.  | 
|  sql\$1latin1\$1general\$1cp1\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt) prenant en charge les caractères latins.  | 
|  sql\$1latin1\$1general\$1cp1253\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1253.txt) prenant en charge les caractères latins.  | 
|  sql\$1latin1\$1general\$1cp1254\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1254.txt) prenant en charge les caractères latins.  | 
|  sql\$1latin1\$1general\$1cp1255\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1255.txt) prenant en charge les caractères latins.  | 
|  sql\$1latin1\$1general\$1cp1256\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1256.txt) prenant en charge les caractères latins.  | 
|  sql\$1latin1\$1general\$1cp1257\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1257.txt) prenant en charge les caractères latins.  | 
|  sql\$1latin1\$1general\$1cp1258\$1ci\$1as  |  [Classement non déterministe](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1258.txt) prenant en charge les caractères latins.  | 
|  chinese\$1prc\$1ci\$1as  |  Classement non déterministe prenant en charge le chinois (RPC).  | 
|  cyrillic\$1general\$1ci\$1as  |  Classement non déterministe prenant en charge l’alphabet cyrillique.  | 
|  finnish\$1swedish\$1ci\$1as  |  Classement non déterministe prenant en charge le finnois.  | 
|  french\$1ci\$1as  |  Classement non déterministe prenant en charge le français.  | 
|  japanese\$1ci\$1as  | Classement non déterministe prenant en charge le japonais. Pris en charge dans Babelfish 2.1.0 et versions ultérieures. | 
|  korean\$1wansung\$1ci\$1as  |  Classement non déterministe prenant en charge le coréen (avec tri par dictionnaire).  | 
|  latin1\$1general\$1ci\$1as  |  Classement non déterministe prenant en charge les caractères latins.  | 
|  modern\$1spanish\$1ci\$1as  |  Classement non déterministe prenant en charge l’espagnol moderne.  | 
|  polish\$1ci\$1as  |  Classement non déterministe prenant en charge le polonais.  | 
|  thai\$1ci\$1as  |  Classement non déterministe prenant en charge le thaï.  | 
|  traditional\$1spanish\$1ci\$1as  |  Classement non déterministe prenant en charge l’espagnol (tri traditionnel).  | 
|  turkish\$1ci\$1as  |  Classement non déterministe prenant en charge le turc.  | 
|  ukrainian\$1ci\$1as  |  Classement non déterministe prenant en charge l’ukrainien.  | 
|  vietnamese\$1ci\$1as  |  Classement non déterministe prenant en charge le vietnamien.  | 

Vous pouvez utiliser les classements suivants comme classements d’objets.<a name="bfish-icu-collations-table"></a>


| Langage | Options déterministes | Options non déterministes | 
| --- | --- | --- | 
|  Arabe  |  Arabic\$1CS\$1AS  |  Arabic\$1CI\$1AS Arabic\$1CI\$1AI  | 
|  Alphabet arabe  |  BBF\$1Unicode\$1CP1256\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1256\$1CS\$1AS  |  BBF\$1Unicode\$1CP1256\$1CI\$1AI BBF\$1Unicode\$1CP1256\$1CS\$1AI  | 
|  Binaire  |  latin1\$1general\$1bin2 BBF\$1Unicode\$1BIN2  |  –  | 
|  Langues d’Europe centrale et d’Europe de l’Est qui utilisent l’alphabet latin  |  BBF\$1Unicode\$1CP1250\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1250\$1CS\$1AS  |  BBF\$1Unicode\$1CP1250\$1CI\$1AI BBF\$1Unicode\$1CP1250\$1CS\$1AI  | 
|  Chinois  |  Chinese\$1PRC\$1CS\$1AS  |  Chinese\$1PRC\$1CI\$1AS Chinese\$1PRC\$1CI\$1AI  | 
|  Cyrillic\$1General  |  Cyrillic\$1General\$1CS\$1AS  |  Cyrillic\$1General\$1CI\$1AS Cyrillic\$1General\$1CI\$1AI  | 
|  Alphabet cyrillique  |  BBF\$1Unicode\$1CP1251\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1251\$1CS\$1AS  |  BBF\$1Unicode\$1CP1251\$1CI\$1AI BBF\$1Unicode\$1CP1251\$1CS\$1AI  | 
|  Estonian  |  Estonian\$1CS\$1AS  |  Estonian\$1CI\$1AS Estonian\$1CI\$1AI  | 
|  Estonien, letton et lituanien  |  BBF\$1Unicode\$1CP1257\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1257\$1CS\$1AS  |  BBF\$1Unicode\$1CP1257\$1CI\$1AI BBF\$1Unicode\$1CP1257\$1CS\$1AI  | 
|  Finnish\$1Swedish  |  Finnish\$1Swedish\$1CS\$1AS  |  Finnish\$1Swedish\$1CI\$1AS Finnish\$1Swedish\$1CI\$1AI  | 
|  Français  |  French\$1CS\$1AS  |  French\$1CI\$1AS French\$1CI\$1AI  | 
|  Grec  |  Greek\$1CS\$1AS  |  Greek\$1CI\$1AS Greek\$1CI\$1AI  | 
|  Hébreu  |  BBF\$1Unicode\$1CP1255\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1255\$1CS\$1AS Hebrew\$1CS\$1AS  |  BBF\$1Unicode\$1CP1255\$1CI\$1AI BBF\$1Unicode\$1CP1255\$1CS\$1AI Hebrew\$1CI\$1AS Hebrew\$1CI\$1AI  | 
|  Japonais (Babelfish 2.1.0 et versions ultérieures)  | Japanese\$1CS\$1AS | Japanese\$1CI\$1AI Japanese\$1CI\$1AS | 
|  Korean\$1Wamsung  |  Korean\$1Wamsung\$1CS\$1AS  |  Korean\$1Wamsung\$1CI\$1AS Korean\$1Wamsung\$1CI\$1AI  | 
|  Caractères latins pour la page de code CP1252  |  latin1\$1general\$1cs\$1as BBF\$1Unicode\$1General\$1CS\$1AS BBF\$1Unicode\$1General\$1Pref\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1\$1CS\$1AS BBF\$1Unicode\$1CP1\$1CS\$1AS  |  latin1\$1general\$1ci\$1as latin1\$1general\$1ci\$1ai latin1\$1general\$1cs\$1ai BBF\$1Unicode\$1General\$1CI\$1AI BBF\$1Unicode\$1General\$1CS\$1AI BBF\$1Unicode\$1CP1\$1CI\$1AI BBF\$1Unicode\$1CP1\$1CS\$1AI  | 
|  Grec moderne  |  BBF\$1Unicode\$1CP1253\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1253\$1CS\$1AS  |  BBF\$1Unicode\$1CP1253\$1CI\$1AI BBF\$1Unicode\$1CP1253\$1CS\$1AI  | 
|  Modern\$1Spanish  |  Modern\$1Spanish\$1CS\$1AS  |  Modern\$1Spanish\$1CI\$1AS Modern\$1Spanish\$1CI\$1AI  | 
|  Mongol  |  Mongolian\$1CS\$1AS  |  Mongolian\$1CI\$1AS Mongolian\$1CI\$1AI  | 
|  Polonais  |  Polish\$1CS\$1AS  |  Polish\$1CI\$1AS Polish\$1CI\$1AI  | 
|  Thaï  |  BBF\$1Unicode\$1CP874\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP874\$1CS\$1AS Thai\$1CS\$1AS  |  BBF\$1Unicode\$1CP874\$1CI\$1AI BBF\$1Unicode\$1CP874\$1CS\$1AI Thai\$1CI\$1AS, Thai\$1CI\$1AI  | 
|  Traditional\$1Spanish  |  Traditional\$1Spanish\$1CS\$1AS  |  Traditional\$1Spanish\$1CI\$1AS Traditional\$1Spanish\$1CI\$1AI  | 
|  Turc  |  BBF\$1Unicode\$1CP1254\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1254\$1CS\$1AS Turkish\$1CS\$1AS  |  BBF\$1Unicode\$1CP1254\$1CI\$1AI BBF\$1Unicode\$1CP1254\$1CS\$1AI Turkish\$1CI\$1AS, Turkish\$1CI\$1AI  | 
|  Ukrainien  |  Ukrainian\$1CS\$1AS  |  Ukranian\$1CI\$1AS Ukranian\$1CI\$1AI  | 
|  Vietnamien  |  BBF\$1Unicode\$1CP1258\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1258\$1CS\$1AS Vietnamese\$1CS\$1AS  |  BBF\$1Unicode\$1CP1258\$1CI\$1AI BBF\$1Unicode\$1CP1258\$1CS\$1AI Vietnamese\$1CI\$1AS Vietnamese\$1CI\$1AI  | 

## Comportement de classement par défaut dans Babelfish
<a name="babelfish-collations-default"></a>

Auparavant, le classement par défaut des types de données pouvant être classées était `pg_catalog.default`. Les types de données et les objets qui dépendent de ces types de données sont classés selon le classement sensible à la casse. Cette condition peut avoir un impact sur les objets T-SQL du jeu de données avec un classement sensible à la casse. À partir de Babelfish 2.3.0, le classement par défaut pour les types de données pouvant être classées (à l’exception de TEXT et NTEXT) est le même que le classement du paramètre `babelfishpg_tsql.server_collation_name`. Lorsque vous passez à Babelfish 2.3.0, le classement par défaut est sélectionné automatiquement au moment de la création du cluster de bases de données, ce qui n’a aucun impact visible. 

# Gestion des classements
<a name="collation.managing"></a>

La bibliothèque ICU fournit un suivi des versions des classements afin que les index qui reposent sur les classements puissent être réindexés lorsqu'une nouvelle version d'ICU est disponible. Pour savoir si votre base de données actuelle comporte des classements qui doivent être actualisés, vous pouvez utiliser la requête suivante après vous être connecté avec `psql` ou `pgAdmin` :

```
SELECT pg_describe_object(refclassid, refobjid,
    refobjsubid) AS "Collation", 
    pg_describe_object(classid, objid, objsubid) AS "Object" 
    FROM pg_depend d JOIN pg_collation c ON refclassid = 'pg_collation'::regclass
    AND refobjid = c.oid WHERE c.collversion <> pg_collation_actual_version(c.oid) 
    ORDER BY 1, 2;
```

Cette requête renvoie la sortie suivante :

```
 Collation | Object
-----------+--------
(0 rows)
```

Dans cet exemple, aucun classement n'a besoin d'être mis à jour.

Pour obtenir la liste des classements prédéfinis dans votre base de données Babelfish, vous pouvez utiliser `psql` ou `pgAdmin` avec la requête suivante :

```
SELECT * FROM pg_collation;
```

Les classements prédéfinis sont stockés dans la table `sys.fn_helpcollations`. Vous pouvez utiliser la commande suivante pour afficher des informations sur un classement (comme ses indicateurs lcid, style et collate). Pour obtenir la liste de tous les classements à l'aide de `sqlcmd`, connectez-vous au port T-SQL (1433, par défaut) et exécutez la requête suivante : 

```
1> :setvar SQLCMDMAXVARTYPEWIDTH 40
2> :setvar SQLCMDMAXFIXEDTYPEWIDTH 40
3> SELECT * FROM fn_helpcollations()
4> GO
name                                     description
---------------------------------------- ----------------------------------------
arabic_cs_as                             Arabic, case-sensitive, accent-sensitive
arabic_ci_ai                             Arabic, case-insensitive, accent-insensi
arabic_ci_as                             Arabic, case-insensitive, accent-sensiti
bbf_unicode_bin2                         Unicode-General, case-sensitive, accent-
bbf_unicode_cp1250_ci_ai                 Default locale, code page 1250, case-ins
bbf_unicode_cp1250_ci_as                 Default locale, code page 1250, case-ins
bbf_unicode_cp1250_cs_ai                 Default locale, code page 1250, case-sen
bbf_unicode_cp1250_cs_as                 Default locale, code page 1250, case-sen
bbf_unicode_pref_cp1250_cs_as            Default locale, code page 1250, case-sen
bbf_unicode_cp1251_ci_ai                 Default locale, code page 1251, case-ins
bbf_unicode_cp1251_ci_as                 Default locale, code page 1251, case-ins
bbf_unicode_cp1254_ci_ai                 Default locale, code page 1254, case-ins
...
(124 rows affected)
```

Les lignes 1 et 2 de l'exemple limitent la sortie à des fins de lisibilité de la documentation uniquement. 

```
1> SELECT SERVERPROPERTY('COLLATION')
2> GO
serverproperty
---------------------------------------------------------------------------
sql_latin1_general_cp1_ci_as

(1 rows affected)
1>
```

# Limites et différences de comportement des classements
<a name="collation.limitations"></a>

Babelfish utilise la bibliothèque ICU pour la prise en charge des classements. PostgreSQL repose sur une version spécifique d'ICU et ne peut correspondre qu'à une seule version d'un classement. Les variations d'une version à l'autre sont inévitables, de même que les variations mineures dans le temps à mesure que les langues évoluent. La liste suivante répertorie les limites et variations de comportement connues pour les classements Babelfish :
+ **Index et dépendance de type de classement** : un index figurant sur un type défini par l'utilisateur qui dépend de la bibliothèque de classements International Components for Unicode (ICU – la bibliothèque utilisée par Babelfish) n'est pas invalidé lorsque la version de la bibliothèque est modifiée.
+ **Fonction COLLATIONPROPERTY** : les propriétés de classement ne sont implémentées que pour les classements Babelfish BBF pris en charge. Pour plus d’informations, consultez le [Babelfish supported collations table](babelfish-collations.md#bfish-collations-table).
+ **Différences entre les règles de tri Unicode** : les classements SQL pour SQL Server trient les données codées en Unicode (`nchar` et `nvarchar`) différemment des données qui ne sont pas codées en Unicode (`char` et `varchar`). Les bases de données Babelfish sont toujours codées en UTF-8 et appliquent toujours les règles de tri Unicode de manière cohérente, quel que soit le type de données. L'ordre de tri de `char` ou `varchar` est donc identique à celui de `nchar` ou `nvarchar`.
+ **Classements à égalité secondaire et comportement de tri** : le classement ICU Unicode secondaire par défaut (`CI_AS`) trie les signes de ponctuation et les autres caractères non alphanumériques avant les caractères numériques, et les caractères numériques avant les caractères alphabétiques. Toutefois, l'ordre des signes de ponctuation et des autres caractères spéciaux est différent. 
+ **Classements tertiaires, solution de contournement pour ORDER BY** : les classements SQL, tels que `SQL_Latin1_General_Pref_CP1_CI_AS`, prennent en charge la fonction `TERTIARY_WEIGHTS` et la capacité à trier les chaînes considérées comme égales au sein d'un classement `CI_AS` afin que le tri s'effectue d'abord sur les majuscules : `ABC`, `ABc`, `AbC`, `Abc`, `aBC`, `aBc`, `abC` et enfin `abc`. Ainsi, la fonction analytique `DENSE_RANK OVER (ORDER BY column)` évalue ces chaînes comme ayant le même rang, mais les classe en commençant par les majuscules au sein d'une partition.

  Vous pouvez obtenir un résultat similaire avec Babelfish en ajoutant une clause `COLLATE` à la clause `ORDER BY` qui spécifie un classement `CS_AS` tertiaire indiquant `@colCaseFirst=upper`. Toutefois, le modificateur `colCaseFirst` s'applique uniquement aux chaînes qui présentent une égalité tertiaire (plutôt qu'une égalité secondaire comme avec le classement `CI_AS`). Par conséquent, vous ne pouvez pas émuler des classements SQL tertiaires à l'aide d'un seul classement ICU. 

  Pour contourner ce problème, nous vous recommandons de modifier les applications qui utilisent le classement `SQL_Latin1_General_Pref_CP1_CI_AS` afin d'utiliser le classement `BBF_SQL_Latin1_General_CP1_CI_AS` en premier. Ajoutez ensuite `COLLATE BBF_SQL_Latin1_General_Pref_CP1_CS_AS` à n'importe quelle clause `ORDER BY` de cette colonne.
+ **Extension de caractère** : une extension de caractère traite un caractère comme étant égal à une séquence de caractères au niveau primaire. Le classement `CI_AS` par défaut de SQL Server prend en charge l'extension de caractère. Les classements ICU prennent en charge l'extension de caractère uniquement pour les classements insensibles aux accents.

  Lorsqu'une extension de caractère est nécessaire, utilisez un classement `AI` pour les comparaisons. Toutefois, ces classements ne sont actuellement pas pris en charge par l'opérateur LIKE.
+ **Codage char et varchar** : lorsque des classements SQL sont utilisés pour les types de données `char` ou `varchar`, l'ordre de tri des caractères précédant le code ASCII 127 est déterminé par la page de code spécifique de ce classement SQL. Pour les classements SQL, les chaînes déclarées comme `char` ou `varchar` peuvent être triées différemment des chaînes déclarées comme `nchar` ou `nvarchar`.

  PostgreSQL code toutes les chaînes avec le codage de la base de données afin de convertir tous les caractères en UTF-8 et de les trier à l'aide des règles Unicode.

  Étant donné que les classements SQL trient les types de données nchar et nvarchar à l'aide de règles Unicode, Babelfish encode toutes les chaînes du serveur en utilisant UTF-8. Babelfish trie les chaînes nchar et nvarchar de la même manière que les chaînes char et varchar, en utilisant les règles Unicode.
+ **Caractère supplémentaire** : les fonctions SQL Server `NCHAR`, `UNICODE` et `LEN` prennent en charge les caractères des points de code en dehors du plan multilingue de base (BMP) Unicode. En revanche, les classements non SC utilisent des caractères de paire de substitution pour gérer les caractères supplémentaires. Pour les types de données Unicode, SQL Server peut représenter jusqu'à 65 535 caractères en utilisant la norme UCS-2, ou toute la gamme Unicode (1 114 111 caractères) si des caractères supplémentaires sont utilisés. 
+ **Classements sensibles aux kanas (KS)** : un classement sensible aux kanas (KS) traite les caractères japonais (kanas) `Hiragana` et `Katakana` différemment. ICU prend en charge la norme de classement japonaise `JIS X 4061`. Le modificateur de paramètres locaux `colhiraganaQ [on | off]`, désormais obsolète, peut fournir la même fonctionnalité que les classements KS. Toutefois, les classements KS du même nom que ceux de SQL Server ne sont actuellement pas pris en charge par Babelfish.
+ **Classements sensibles à la largeur (WS)** : lorsqu'un caractère d'un seul octet (demi-largeur) et le même caractère représenté par un caractère de deux octets (pleine largeur) sont traités différemment, le classement est dit *sensible à la largeur (WS)*. Les classements WS portant le même nom que ceux de SQL Server ne sont actuellement pas pris en charge par Babelfish.
+ **Classements VSS (sensibilité au sélecteur de variante)** : les classements VSS (sensibilité au sélecteur de variante) font la distinction entre les sélecteurs de variantes idéographiques dans les classements japonais `Japanese_Bushu_Kakusu_140` et `Japanese_XJIS_140`. Une séquence de variantes est constituée d'un caractère de base et d'un sélecteur de variante supplémentaire. Si vous ne sélectionnez pas le champ `_VSS`, le sélecteur de variante n'est pas pris en compte dans la comparaison.

  Les classements VSS ne sont actuellement pas pris en charge par Babelfish.
+ **Classements BIN et BIN2** : un classement BIN2 trie les caractères en fonction de l'ordre des points de code. L'ordre binaire octet par octet du format UTF-8 préserve l'ordre des points de code Unicode, ce qui en fait probablement le classement le plus performant. Si l'ordre des points de code Unicode fonctionne pour une application, n'hésitez pas à utiliser un classement BIN2. Toutefois, l'utilisation d'un classement BIN2 peut entraîner l'affichage des données dans un ordre culturellement inattendu sur le client. De nouveaux mappages vers des caractères minuscules sont ajoutés à Unicode au fil du temps. `LOWER` peut donc fonctionner différemment selon les versions d'ICU. Il s'agit d'un cas particulier du problème plus général de gestion des versions du classement plutôt que d'un problème spécifique au classement BIN2. 

  Babelfish fournit le classement `BBF_Latin1_General_BIN2` avec la distribution Babelfish pour assembler dans l'ordre les points de code Unicode. Dans un classement BIN, seul le premier caractère est trié en tant que wchar. Les autres caractères sont triés octet par octet, dans l'ordre des points de code en fonction de leur encodage. Cette approche ne suit pas les règles de classement Unicode et n'est pas prise en charge par Babelfish.
+ **Classements non déterministes et limite CHARINDEX** : pour les versions de Babelfish antérieures à la version 2.1.0, vous ne pouvez pas utiliser CHARINDEX avec des classements non déterministes. Par défaut, Babelfish utilise un classement insensible à la casse (non déterministe). L'utilisation de CHARINDEX pour les versions antérieures de Babelfish génère l'erreur d'exécution suivante :

  ```
  nondeterministic collations are not supported for substring searches
  ```
**Note**  
Cette limite et cette solution de contournement s'appliquent uniquement à Babelfish version 1.x (Aurora PostgreSQL versions 13.x). Babelfish 2.1.0 et versions ultérieures ne présentent pas ce problème.

  Vous pouvez contourner ce problème de l'une des manières suivantes :
  + Convertir explicitement l'expression en une collation sensible à la casse et respecter la casse des deux arguments en appliquant les instructions LOWER ou UPPER. Par exemple, la commande `SELECT charindex('x', a) FROM t1` deviendrait ce qui suit :

    ```
    SELECT charindex(LOWER('x'), LOWER(a COLLATE sql_latin1_general_cp1_cs_as)) FROM t1
    ```
  + Créez une fonction SQL f\$1charindex, et remplacez les appels à CHARINDEX par des appels à la fonction suivante :

    ```
    CREATE function f_charindex(@s1 varchar(max), @s2 varchar(max)) RETURNS int
    AS
    BEGIN
    declare @i int = 1
    WHILE len(@s2) >= len(@s1)
    BEGIN
      if LOWER(@s1) = LOWER(substring(@s2,1,len(@s1))) return @i
      set @i += 1
      set @s2 = substring(@s2,2,999999999)
    END
    return 0
    END
    go
    ```

# Gestion du traitement des erreurs Babelfish avec des trappes de secours
<a name="babelfish-strict"></a>

Dans la mesure du possible, Babelfish imite le comportement de SQL en ce qui concerne le flux de contrôle et l’état de transaction. Lorsque Babelfish rencontre une erreur, il renvoie un code d’erreur semblable au code d’erreur SQL Server. Si Babelfish ne peut pas mapper l’erreur à un code SQL Server, il renvoie un code d’erreur fixe (`33557097`) et prend des mesures spécifiques en fonction du type d’erreur, comme suit :
+ Pour les erreurs de compilation, Babelfish annule la transaction.
+ Pour les erreurs d’exécution, Babelfish termine le lot et annule la transaction.
+ Pour une erreur de protocole entre le client et le serveur, la transaction n’est pas annulée.

Si un code d’erreur ne peut pas être mappé à un code équivalent et que le code d’une erreur similaire est disponible, il est mappé au code alternatif. Par exemple, les comportements à l’origine des codes SQL Server `8143` et `8144`sont tous deux mappés au code `8143`.

Les erreurs qui ne peuvent pas être mappées ne respectent pas une construction `TRY... CATCH`.

Vous pouvez utiliser `@@ERROR` pour renvoyer un code d’erreur SQL Server, ou la fonction `@@PGERROR` pour renvoyer un code d’erreur PostgreSQL. Vous pouvez également utiliser la fonction `fn_mapped_system_error_list` pour renvoyer une liste de codes d’erreur mappés. Pour en savoir plus sur les codes d’erreur PostgreSQL, consultez [le site Internet PostgreSQL](https://www.postgresql.org/docs/current/errcodes-appendix.html).

## Modification des paramètres de la trappe de secours de Babelfish
<a name="babelfish-escape_hatches"></a>

Pour gérer les déclarations susceptibles d’échouer, Babelfish définit certaines options appelées trappes de secours. Une *trappe de secours* est une option qui spécifie le comportement de Babelfish lorsqu’il rencontre une fonction ou une syntaxe non prise en charge.

Vous pouvez utiliser la procédure stockée `sp_babelfish_configure` pour contrôler les paramètres d’une trappe de secours. Utilisez le script pour définir la trappe de secours sur `ignore` ou `strict`. Si elle est définie sur `strict`, Babelfish renvoie une erreur que vous devez corriger avant de continuer.

Pour appliquer les changements à la session en cours et au niveau du cluster, incluez le mot-clé `server`.

Procédez comme suit :
+ Pour répertorier toutes les trappes de secours et leur statut, ainsi que des informations relatives à leur utilisation, exécutez `sp_babelfish_configure`.
+ Pour répertorier les trappes de secours nommées et leurs valeurs, pour la session en cours ou à l’échelle du cluster, exécutez la commande `sp_babelfish_configure 'hatch_name'` où `hatch_name` correspond à l’identifiant d’une ou de plusieurs trappes de secours. Le nom d’une trappes de secours (*hatch\$1name*) peut utiliser des caractères génériques SQL, tels que « % ».
+ Pour définir une ou plusieurs trappes de secours sur la valeur spécifiée, exécutez `sp_babelfish_configure ['hatch_name' [, 'strict'|'ignore' [, 'server']]`. Pour rendre les paramètres permanents à l’échelle d’un cluster, ajoutez le mot-clé `server`, comme indiqué ci-après :

  ```
  EXECUTE sp_babelfish_configure 'escape_hatch_unique_constraint', 'ignore', 'server'
  ```

  Pour les appliquer à la session en cours uniquement, n’utilisez pas `server`.
+ Pour remettre toutes les trappes de secours à leur valeur par défaut, lancez `sp_babelfish_configure 'default'` (Babelfish 1.2.0 et versions ultérieures). 

La chaîne identifiant la (ou les) trappe(s) peut inclure des caractères génériques SQL. L’exemple suivant définit toutes les trappes de secours syntaxiques à ignorer (`ignore`) pour le cluster Aurora PostgreSQL

```
EXECUTE sp_babelfish_configure '%', 'ignore', 'server'
```

Dans le tableau suivant, vous trouverez les descriptions et les valeurs par défaut des trappes de secours prédéfinies par Babelfish.


| Trappe de secours | Description | Par défaut | 
| --- | --- | --- | 
| escape\$1hatch\$1checkpoint |  Autorise l’utilisation de l’instruction CHECKPOINT dans le code procédural, mais l’instruction CHECKPOINT n’est actuellement pas implémentée.  |  ignore  | 
| escape\$1hatch\$1constraint\$1name\$1for\$1default |  Détermine le comportement de Babelfish pour les noms de contraintes par défaut.  |  ignore  | 
| escape\$1hatch\$1database\$1misc\$1options |  Détermine le comportement de Babelfish pour les options suivantes sur CREATE DATABASE: CONTAINMENT, DB\$1CHAINING, TRUSTWORTHY, PERSISTENT\$1LOG\$1BUFFER.  |  ignore  | 
| escape\$1hatch\$1for\$1replication |  Détermine le comportement de Babelfish pour la clause [NOT] FOR REPLICATION lors de la création ou de la modification d’une table.  |  strict  | 
| escape\$1hatch\$1fulltext |  Détermine le comportement de Babelfish pour les fonctions FULLTEXT telles que DEFAULT\$1FULLTEXT\$1LANGUAGE dans CREATE/ALTER DATABASE, CREATE FULLTEXT INDEX ou sp\$1fulltext\$1database.  |  ignore  | 
| escape\$1hatch\$1ignore\$1dup\$1key |  Contrôle le comportement de Babelfish lié à CREATE/ALTER TABLE et CREATE INDEX. Lorsque la valeur IGNORE\$1DUP\$1KEY=ON, provoque une erreur lorsqu’elle est définie sur `strict` (la valeur par défaut) ou ignore l’erreur lorsqu’elle est définie sur `ignore` (Babelfish version 1.2.0 et ultérieures).   |  strict  | 
| escape\$1hatch\$1index\$1clustering |  Détermine le comportement de Babelfish pour les mots-clés CLUSTERED ou NONCLUSTERED liés aux index et aux contraintes PRIMARY KEY ou UNIQUE. Lorsque CLUSTERED est ignoré, l’index ou la contrainte est créé comme si NONCLUSTERED avait été spécifié.  |  ignore  | 
| escape\$1hatch\$1index\$1columnstore |  Détermine le comportement de Babelfish pour la clause COLUMNSTORE. Si vous spécifiez `ignore`, Babelfish crée un index B-Tree classique.  |  strict  | 
| escape\$1hatch\$1join\$1hints |  Détermine le comportement des mots-clés dans un opérateur JOIN : LOOP, HASH, MERGE, REMOTE, REDUCE, REDISTRIBUTE, REPLICATE.  |  ignore  | 
| escape\$1hatch\$1language\$1non\$1english |  Détermine le comportement de Babelfish pour les langues autres que l’anglais dans les messages affichés à l’écran. Babelfish ne prend actuellement en charge que `us_english` pour les messages affichés à l’écran. SET LANGUAGE peut utiliser une variable contenant le nom de la langue, de sorte que la langue définie ne peut être détectée qu’au moment de l’exécution.  |  strict  | 
| escape\$1hatch\$1login\$1hashed\$1password |  En cas de définition sur ignore, l’erreur liée au mot-clé `HASHED` est supprimée pour `CREATE LOGIN` et `ALTER LOGIN`.  |  strict  | 
| escape\$1hatch\$1login\$1misc\$1options |  En cas de définition sur ignore, l’erreur liée à des mots-clés autres que `HASHED`, `MUST_CHANGE`, `OLD_PASSWORD` et `UNLOCK` est supprimée pour `CREATE LOGIN` et `ALTER LOGIN`.  |  strict  | 
| escape\$1hatch\$1login\$1old\$1password |  En cas de définition sur ignore, l’erreur liée au mot-clé `OLD_PASSWORD` est supprimée pour `CREATE LOGIN` et `ALTER LOGIN`.  |  strict  | 
| escape\$1hatch\$1login\$1password\$1must\$1change |  En cas de définition sur ignore, l’erreur liée au mot-clé `MUST_CHANGE` est supprimée pour `CREATE LOGIN` et `ALTER LOGIN`.  |  strict  | 
| escape\$1hatch\$1login\$1password\$1unlock |  En cas de définition sur ignore, l’erreur liée au mot-clé `UNLOCK` est supprimée pour `CREATE LOGIN` et `ALTER LOGIN`.  |  strict  | 
| escape\$1hatch\$1nocheck\$1add\$1constraint |  Détermine le comportement de Babelfish pour la clause WITH CHECK ou NOCHECK liée aux contraintes.  |  strict  | 
| escape\$1hatch\$1nocheck\$1existing\$1constraint |  Détermine le comportement de Babelfish pour les contraintes FOREIGN KEY ou CHECK.   |  strict  | 
| escape\$1hatch\$1query\$1hints |  Détermine le comportement de Babelfish pour les indicateurs de requête. Lorsque cette option est définie sur ignore, le serveur ignore les indicateurs qui utilisent la clause OPTION (...) pour spécifier les aspects de traitement des requêtes. Les exemples incluent SELECT FROM ... OPTION(MERGE JOIN HASH, MAXRECURSION 10)).  |  ignore  | 
|  escape\$1hatch\$1rowversion | Contrôle le comportement des types de données ROWVERSION et TIMESTAMP. Pour plus d’informations, consultez [Utilisation des fonctionnalités Babelfish dont la mise en œuvre est limitée](babelfish-compatibility.tsql.limited-implementation.md). | strict | 
| escape\$1hatch\$1schemabinding\$1function |  Détermine le comportement de Babelfish pour la clause WITH SCHEMABINDING. Par défaut, la clause WITH SCHEMABINDING est ignorée lorsqu’elle est spécifiée avec la commande CREATE ou ALTER FUNCTION.   |  ignore  | 
| escape\$1hatch\$1schemabinding\$1procedure |  Détermine le comportement de Babelfish pour la clause WITH SCHEMABINDING. Par défaut, la clause WITH SCHEMABINDING est ignorée lorsqu’elle est spécifiée avec la commande CREATE ou ALTER PROCEDURE.   |  ignore  | 
| escape\$1hatch\$1rowguidcol\$1column |  Détermine le comportement de Babelfish pour la clause ROWGUIDCOL lors de la création ou de la modification d’une table.  |  strict  | 
| escape\$1hatch\$1schemabinding\$1trigger |  Détermine le comportement de Babelfish pour la clause WITH SCHEMABINDING. Par défaut, la clause WITH SCHEMABINDING est ignorée lorsqu’elle est spécifiée avec la commande CREATE ou ALTER TRIGGER.  |  ignore  | 
| escape\$1hatch\$1schemabinding\$1view |  Détermine le comportement de Babelfish pour la clause WITH SCHEMABINDING. Par défaut, la clause WITH SCHEMABINDING est ignorée lorsqu’elle est spécifiée avec la commande CREATE ou ALTER VIEW.  |  ignore  | 
| escape\$1hatch\$1session\$1settings |  Détermine le comportement de Babelfish à l’égard des instructions SET non prises en charge au niveau de la session.  |  ignore  | 
| escape\$1hatch\$1showplan\$1all |  Contrôle le comportement de Babelfish lié à SET SHOWPLAN\$1ALL et SET STATISTICS PROFILE. Lorsqu’ils sont définis sur ignore (ignorer), ils se comportent comme SET BABELFISH\$1SHOWPLAN\$1ALL et SET BABELFISH\$1STATISTICS PROFILE ; lorsqu’ils sont définis sur strict, ils sont ignorés en silence.  |  strict  | 
| escape\$1hatch\$1storage\$1on\$1partition |  Détermine le comportement de Babelfish pour la clause `ON partition_scheme column ` lors de la définition du partitionnement. Babelfish n’implémente actuellement pas le partitionnement.  |  strict  | 
| escape\$1hatch\$1storage\$1options |  Trappe de secours associée à une option de stockage utilisée dans CREATE, ALTER DATABASE, TABLE, INDEX. Cela inclut les clauses (LOG) ON, TEXTIMAGE\$1ON, FILESTREAM\$1ON qui définissent les emplacements de stockage (partitions, groupes de fichiers) des tables, index et contraintes, ainsi que d’une base de données. Ce paramètre de trappe de secours s’applique à toutes ces clauses (y compris ON [PRIMARY] et ON "DEFAULT"). Une exception s’applique lorsqu’une partition est spécifiée pour une table ou un index accompagné de ON partition\$1scheme (column).  |  ignore  | 
| escape\$1hatch\$1table\$1hints |  Détermine le comportement des indicateurs de table spécifiés à l’aide de la clause WITH (...).   |  ignore  | 
| escape\$1hatch\$1unique\$1constraint |  Lorsqu’elle est définie comme stricte, une obscure différence sémantique entre SQL Server et PostgreSQL dans le traitement des valeurs NULL sur les colonnes indexées peut entraîner des erreurs. La différence sémantique n’apparaît que dans des cas d’utilisation irréalistes. Vous pouvez donc définir cette trappe de secours sur « ignorer » pour ne pas afficher l’erreur.  Obsolète à partir des versions suivantes 3.6.0 et ultérieures et des versions 4.2.0 et ultérieures  |  strict  | 