La réponse simple est que, contrairement à MySQL, les jeux de caractères ne peuvent pas être définis à niveau colonne (ou tableau)
. Latin1
n'est pas non plus un jeu de caractères Oracle valide.
Les jeux de caractères sont cohérents dans toute la base de données et auront été spécifiés lors de la création de la base de données. Vous pouvez trouver votre personnage en interrogeant NLS_DATABASE_PARAMETERS
,
select value
from nls_database_parameters
where parameter = 'NLS_CHARACTERSET'
La liste complète des jeux de caractères possibles est disponible pour 11g r2
et pour 9i
ou vous pouvez interroger V$NLS_VALID_VALUES
.
Il est possible d'utiliser le ALTER SESSION
déclaration
pour définir le NLS_LANGUAGE
ou le NLS_TERRITORY
, mais malheureusement, vous ne pouvez pas le faire pour le jeu de caractères. Je pense que c'est parce que la modification de la langue change la façon dont Oracle afficherait les données stockées alors que la modification du jeu de caractères modifierait la façon dont Oracle stocke les données.
Lors de l'affichage des données, vous pouvez bien sûr spécifier le jeu de caractères requis dans le client que vous utilisez.
Migration du jeu de caractères n'est pas une tâche triviale et ne doit pas être fait à la légère.
En passant, pourquoi essayez-vous d'utiliser Latin 1 ? Il serait plus normal de configurer une nouvelle base de données dans quelque chose comme UTF-8 (autrement connu sous le nom de AL32UTF8
- ne pas utiliser UTF8
) ou UTF-16 afin que vous puissiez stocker efficacement des données multi-octets. Même si vous n'en avez pas besoin maintenant, il est sage d'essayer - sans garantie dans la vie - de pérenniser votre base de données sans avoir besoin de migrer à l'avenir.
Si vous cherchez à spécifier différents jeux de caractères pour différentes colonnes dans une base de données, la meilleure option serait de déterminer si cette exigence est vraiment nécessaire et d'essayer de la supprimer. Si cela est absolument nécessaire, votre meilleur pari pourrait être d'utiliser un jeu de caractères qui est un sur-ensemble de tous les jeux de caractères potentiels. Ensuite, ayez une sorte de contrainte de vérification qui limite la colonne à des valeurs hexadécimales spécifiques. Je ne recommanderais pas du tout de faire cela, le potentiel d'erreurs est énorme et extrêmement complexe. De plus, différents jeux de caractères rendent différentes valeurs hexadécimales différemment. Ceci, à son tour, signifie que vous devez imposer qu'une colonne soit rendue dans un caractère spécifique, ce qui est impossible car elle ne relève pas de la portée de la base de données.