Export/import de 8i ver 9i et perte des accents [Résolu]

[Pilru]

Bonjour,

Voici mon problème :

Nous exportont un schema d'un base 8i vers une 9i.
L'export et l'import se passent sans problèmes (pas d'erreurs, ni d'avertissements). Sauf que les lettres avec accent ne sont pas importées dans la 9i.
A la place on y trouve soit des ? inversés, soit d'autres signes. Ceci en fonction du nls_lang utilisé par le client. Mais jamais les accents ne sont affichés.

J'ai essayé de jouer avec la variable d'environnement NLS_LANG au moment de l'export et de l'import. Mais rien n'y fait. Impossible de récupérer les accents.

Voici quelques infos :

BDD source 8i :

* nls_database_parameters :

Code :

1
2
3
4
5
6
7
8
 
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CHARACTERSET               WE8ISO8859P1
NLS_NCHAR_CHARACTERSET         WE8ISO8859P1
NLS_RDBMS_VERSION              8.1.7.0.0

* nls_session_parameters :

Code :

1
2
3
4
5
6
 
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE                   FRENCH
NLS_TERRITORY                  FRANCE
NLS_COMP                       BINARY

BDD cible 9i :

* nls_database_parameters :

Code :

1
2
3
4
5
6
7
8
9
10
 
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CHARACTERSET               WE8MSWIN1252
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
NLS_RDBMS_VERSION              9.2.0.7.0

* nls_session_parameters :

Code :

1
2
3
4
5
6
7
8
 
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE                   FRENCH
NLS_TERRITORY                  FRANCE
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE

Le tout fonctionnant sur des serveurs Windows 2003.
L'export et l'import se font par batch dans une console cmd.

Pour l'instant je sèche complètement.

[pifor]

Il faut nous donner les 2 valeurs de NLS_LANG:

• Quelle est la valeur de NLS_LANG pour le code applicatif qui fait les INSERT ou les UPDATE sur les données de la base 8i (Si la partie jeu de caractères NLS_LANG est la même que le jeu de caractères de la base, il y a un risque de "corruption" car Oracle ne fait plus de vérification ou conversion avant de stocker les caractères dans la base) ?
• Quelle est la valeur de NLS_LANG dans l'environnement où l'affichage est incorrect ?

Essayez de comparer sur les bases 8i et 9i le contenu d'une colonne concernée qui contient un 'é' avec la fonction DUMP SQL:

Code :

SELECT dump(<colonne>, 1017) FROM <table>;

avec par exemple:

Code :

SELECT dump('é', 1017) FROM dual;

Voir aussi le tutoriel NLS.

[Pilru]

La valeur de NLS_LANG pour que l'affichage soit correct en console est : FRENCH.FRANCE.WE8ISO8859P1.

Les dump sur les 'é' et 'è' sont identique pour les deux BDD, a savoir :

é = 82
è = 8a

L'encodage sur la 8i est correcte :

Code :

Typ=1 Len=13 CharacterSet=WE8ISO8859P1: E,n,v,o,i, ,r,82,p,o,n,s,e

En revanche, une fois la table importée sur la 9i, l'encodage n'est plus le même :

Code :

Typ=1 Len=13 CharacterSet=WE8MSWIN1252: E,n,v,o,i, ,r,bf,p,o,n,s,e

Il y a bien une conversion, mais quand et pourquoi, mystère.

[LeoAnderson]

pouvez-vous nous donner les premières lignes des logs d'export et d'import ?

[pifor]

Dans les 2 jeux de caractères, 'é' et 'è' ont la même représentation binaire d'après les tables 8859-1 et Windows-1252. J'ai également vérifié avec deux bases en 10.2 chacune ayant le bon jeu de caractères::

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
SQL> SELECT dump (x, 1017) FROM t;
 
DUMP(X,1017)
--------------------------------------------------------------------------------
 
Typ=1 Len=2 CharacterSet=WE8MSWIN1252: e9,e8
 
SQL> SELECT *  FROM t;
 
X
--------------------------------------------------------------------------------
 
éè

et

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
SQL> SELECT  * FROM t;
 
X
--------------------------------------------------------------------------------
 
éè
 
SQL> SELECT dump (x, 1017) FROM t;
 
DUMP(X,1017)
--------------------------------------------------------------------------------
 
Typ=1 Len=2 CharacterSet=WE8ISO8859P1: e9,e8

Cela signifie que dans votre cas les données sont mauvaises dans la base source.

[Pilru]

Voici :

Export fait avec NLS_LANG=FRENCH_FRANCE.WE8ISO8859P1 (NLS_LANG qui me permet d'avoir les accent lors d'une requête par sqlplus).

Code :

1
2
3
4
Connecté à: Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
JServer Release 8.1.7.0.0 - Production
Export fait dans le jeu de car WE8ISO8859P1 et jeu de car NCHAR WE8ISO8859P1
Prêt à exporter les TABLES spécifiées ... via le chemin classique...

Import fait avec NLS_LANG=FRENCH_FRANCE.WE8MSWIN1252

Code :

1
2
3
4
5
6
Connecté à : Oracle9i Enterprise Edition Release 9.2.0.7.0 - Production
WITH the Partitioning, OLAP AND Oracle DATA Mining options
JServer Release 9.2.0.7.0 - Production
Fichier d'export créé par EXPORT:V08.01.07 via le chemin classique
import effectué dans le jeu de caractères WE8MSWIN1252 et le jeu NCHAR AL16UTF16
le serveur d'import utilise le jeu de caractères NCHAR WE8ISO8859P1 (conversion possible)

Merci pour votre aide...

[Pilru]

J'ai l'explication :

Dans la table source, les données sont codées en WE8PC850.
Lors d'une requête avec un NLS_LANG=NLS_LANG=FRENCH_FRANCE.WE8ISO8859P1 (characterset correspondant a celui de la BDD), l'affichage est correct puisqu'aucune conversion n'est faite.

Lors de l'export, Oracle pense que les données sont en WE8ISO8859P1, ne fait pas de conversion. Le fichier dump contient donc des donnée codées en WE8PC850.

Lors de l'import, Oracle reconnait le fichier comme ayant été exporté en WE8ISO8859P1 et fait la conversion vers WE8MSWIN1252.

La solution :

Exporter les données avec nls à WE8ISO8859P1.
Modifier le fichier dmp pour qu'Oracle le reconnaisse comme ayant était créé en WE8PC850 (2 octets à modifier).

J'ai testé, ça marche

[pifor]

Envoyé par Pilru

J'ai l'explication :

Dans la table source, les données sont codées en WE8PC850.
Lors d'une requête avec un NLS_LANG=NLS_LANG=FRENCH_FRANCE.WE8ISO8859P1 (characterset correspondant a celui de la BDD), l'affichage est correct puisqu'aucune conversion n'est faite.

Lors de l'export, Oracle pense que les données sont en WE8ISO8859P1, ne fait pas de conversion. Le fichier dump contient donc des donnée codées en WE8PC850.
:

Cela ne correspond pas aux informations données dans votre premier message ! Oracle fait une conversion des données caractère entre le serveur et le client si les jeux de caractères de la base et celui indiqué par NLS_LANG sont différents. C'est justement si les jeux sont les mêmes qu'il y a un risque d'après le Globalization Guide.

Envoyé par Pilru

La solution :

Exporter les données avec nls à WE8ISO8859P1.
Modifier le fichier dmp pour qu'Oracle le reconnaisse comme ayant était créé en WE8PC850 (2 octets à modifier).

J'ai testé, ça marche :yaisse2
:

Modifier directement un fichier export qui utilise un format binaire (même si on peut afficher certaines parties en ASCII) n'est pas du tout supporté par Oracle.

[Pilru]

Cela ne correspond pas aux informations données dans votre premier message ! Oracle fait une conversion des données caractère entre le serveur et le client si les jeux de caractères de la base et celui indiqué par NLS_LANG sont différents.

Si, ça correspond. Le characterset de la base est WE8ISO8859P1. Est fixant le NLS_LANG à FRENCH_FRANCE.WE8ISO8859P1 sur le client, l'export ne converti pas. Je peux le vérifier par les sorties de la commande d'export et par le contenu du fichier d'export.

Modifier directement un fichier export qui utilise un format binaire (même si on peut afficher certaines parties en ASCII) n'est pas du tout supporté par Oracle.

Un éditeur hexadécimal fait l'affaire. J'ai modifiés 2 octets, pas 2 caractères.
Et cela fonctionne très bien.

[pifor]

Ce qui est contradictoire c'est ça:

Dans la table source, les données sont codées en WE8PC850.

et

Typ=1 Len=13 CharacterSet=WE8ISO8859P1: E,n,v,o,i, ,r,82,p,o,n,s,e

et

NLS_CHARACTERSET WE8ISO8859P1

[Pilru]

Le progiciel doit envoyer les datas en WE8CP850 au serveur et ce dernier pense les recevoir en WE8ISO8859P1.

Ce qui se vérifie avec

Code :

Typ=1 Len=13 CharacterSet=WE8ISO8859P1: E,n,v,o,i, ,r,82,p,o,n,s,e

82 correspondant au é dans la codepage 850.