Oui, si votre base de données Oracle est créée à l'aide d'un jeu de caractères Unicode, un NVARCHAR dans SQL Server doit être migré vers un VARCHAR2 dans Oracle. Dans Oracle, le NVARCHAR Le type de données existe pour permettre aux applications de stocker des données à l'aide d'un jeu de caractères Unicode lorsque le jeu de caractères de la base de données ne prend pas en charge Unicode.
Une chose dont il faut tenir compte lors de la migration, cependant, est la sémantique de la longueur des caractères. Dans SQL Server, un NVARCHAR(20) alloue de l'espace pour 20 caractères, ce qui nécessite jusqu'à 40 octets dans UCS-2. Dans Oracle, par défaut, un VARCHAR2(20) alloue 20 octets de stockage. Dans le AL32UTF8 jeu de caractères, qui est potentiellement assez d'espace pour 6 caractères bien qu'il en gère probablement beaucoup plus (un seul caractère dans AL32UTF8 nécessite entre 1 et 3 octets. Vous souhaitez probablement déclarer vos types Oracle en tant que VARCHAR2(20 CHAR) qui indique que vous souhaitez allouer de l'espace pour 20 caractères, quel que soit le nombre d'octets requis. Cela a tendance à être beaucoup plus facile à communiquer que d'essayer d'expliquer pourquoi certaines chaînes de 20 caractères sont autorisées alors que d'autres chaînes de 10 caractères sont rejetées.
Vous pouvez modifier la sémantique de longueur par défaut au niveau de la session afin que toutes les tables que vous créez sans spécifier de sémantique de longueur utilisent une sémantique de caractères plutôt que d'octets
ALTER SESSION SET nls_length_semantics=CHAR;
Cela vous permet d'éviter de taper CHAR chaque fois que vous définissez une nouvelle colonne. Il est également possible de définir cela au niveau du système, mais cela est déconseillé par l'équipe NLS. a été modifié. Et probablement très peu de scripts tiers l'ont été.
