Discussion :

[nmathon]

Bonjour,

J'ai envoyé un dump à mon fournisseur logiciel, notre base est en NLS_LANG à CANADIAN FRENCH_CANADA.WE8MSWIN1252 et le NCHAR character set à AL16UTF16.c

De son côté, la base est en AMERICAN_AMERICA.WE8MSWIN1252 avec le NCHAR character set à AL32UTF8.

Il croit que c'est le problème de son importation qui plante avec l'erreur suivante:

IMP-00019: row rejected due to ORACLE error 12899
IMP-00003: ORACLE error 12899 encountered
ORA-12899: value too large for column XXX

Puis-je convertir ma base avec EXP afin qu'il n'ait pas de problème pour l'import?

Merci!

[Pomalaix]

Il faut bien distinguer la variable d'environnement NLS_LANG, et le jeu de caractères de la base.

Vous pouvez contrôler ce dernier simplement :

Code :

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

1
2
3
select property_name, property_value 
from database_properties
where property_name like '%CHARACTERSET%';

Quel est le résultat sur les bases respectives ?

[nmathon]

Après avoir reçu la réponse du fournisseur, c'est comme vous avez dit, le character set qui est en cause. Voici l'information.

Sur la base source:

NLS_CHARACTERSET
WE8MSWIN1252

NLS_NCHAR_CHARACTERSET
AL16UTF16

Sur la base cible:

NLS_CHARACTERSET
AL32UTF8

NLS_NCHAR_CHARACTERSET
AL16UTF16

Maintenant, comment puis-je exporter de WE8MSWIN1252 à AL32UTF8 via EXP? A moins qu'une commande existe avec IMP?

Merci!

[Pomalaix]

A mon sens, c'est à votre fournisseur de se débrouiller : qu'il crée une base en WE8MSWIN1252, et il n'aura pas de souci à importer vos données.

[nmathon]

D'accord, mais à ce que j'en comprends, il n'y a rien à faire que de créer une nouvelle base?

Merci!

[Pomalaix]

D'accord, mais à ce que j'en comprends, il n'y a rien à faire que de créer une nouvelle base?

Votre fournisseur a besoin pour une raison quelconque de dupliquer vos données ? Il y en a pour 10 minutes pour créer une base vide "jetable" avec le jeu de caractères de son choix.

De votre côté c'est votre base de prod je suppose, donc il n'y a pas de raison de la bricoler.
Et si vous vouliez le faire, vous y passeriez bien plus que 10 minutes, sans parler des risques sur votre production.

Quelle est votre version au fait ?

[nmathon]

11g R2

Évidemment, c'est plus simple pour lui de créer une nouvelle base vide. Je posais la question au cas où j'aurais pu ajouter un argument à la commande EXP qui aurait fait une conversion de mon character set au sien mais ça ne semble pas le cas!

Merci!

[Pomalaix]

Dans votre cas, la base source utilise un octet par caractère, alors que la base cible utilise dans certains cas plusieurs octets par caractère.

Par défaut, un VARCHAR2(10) s'entend comme supportant une longueur maximale de 10 octets, or dans la base cible 10 octets ne suffiront pas forcément à stocker 10 caractères, d'où votre erreur à l'import.

Donc, dans le principe, ce qu'il faudrait, c'est que l'export enregistre dans le fichier DMP un VARCHAR2(10 CHAR) alors qu'en base c'est VARCHAR2(10 BYTE).
Une telle option n'existe pas avec l'export classique (EXP).

Comme vous êtes en V11, vous devriez plutôt utiliser Datapump, mais ses options normales ne permettent pas non plus une telle conversion.
C'est peut-être possible en faisant l'export en PL/SQL (avec DBMS_METADATA + DBMS_DATAPUMP), si vous avez une soirée d'hiver à gaspiller...