Discussion :

[Jinx02]

Bonjour,

J'ai un problème d'import ou plus exactement de restitution à l'écran de caractères accentués ou spéciaux.
par exemple : le "é" apparait comme un "i" ou le "°" apparait comme un "0".

L'export vient d'un serveur Unix en Oracle 8.1.7 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
SQL> * from nls_database_parameters;
 
PARAMETER                      VALUE
------------------------------ --------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               US7ASCII
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_SORT                       BINARY
NLS_TIME_FORMAT                HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZH:TZM
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZH:TZM
NLS_DUAL_CURRENCY              $
NLS_COMP                       BINARY
NLS_NCHAR_CHARACTERSET         US7ASCII
NLS_RDBMS_VERSION              8.1.7.0.0

A priori, le NLS_LANG n'est pas défini sur l'UNIX uniquement le ORA_NLS33.

Et l'export se fait sur un Windows 2003 SP2 en Oracle 10.2.0.4.0 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
  1* select * from nls_database_parameters
 
PARAMETER                      VALUE
------------------------------ ----------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               US7ASCII
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_SORT                       BINARY
NLS_TIME_FORMAT                HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY              $
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_RDBMS_VERSION              10.2.0.4.0

[pifor]

Il y a un problème de fond: si la base a le jeu de caractères US7ASCII elle ne peut pas stocker correctement de caractères accentués puisque US7ASCII ne comporte pas ces caractères. Vos données sont incohérentes car vous avez probablement NLS_LANG positionné à US7ASCII et dans ce cas Oracle ne vérifie pas que les données entre le client et la base

Voir le tutoriel NLS: http://fadace.developpez.com/oracle/nls/.

Il faut envisager un changement de jeu de caractères avec correction des données ...

[Jinx02]

Merci pour votre réponse, mais c'est très étrange car j'ai bien des accents sur l'ancienne base sur l'UNIX... ???

[Jinx02]

De plus, ce n'est que à la reprise (import) des données que cela ne fonctionne pas car à l'insertion de nouvelles données, j'ai bien mes accents...

[pifor]

Vérifiez avec la fonction DUMP le véritable contenu d'une colonne.
Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
SQL> select * from nls_database_parameters where parameter like '%SET%';
 
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_CHARACTERSET               WE8ISO8859P15
NLS_NCHAR_CHARACTERSET         AL16UTF16
 
SQL> create table t2(x varchar2(10));
 
Table created.
 
SQL> insert into t2 values ('é');
 
1 row created.
 
SQL> select * from t2;
 
X
----------
é
 
 
SQL> select dump(x,1017) from t2;
 
DUMP(X,1017)
--------------------------------------------------------------------------------
Typ=1 Len=1 CharacterSet=WE8ISO8859P15: e9

Dans votre cas, comparez avec la table ASCII le code caractère accentué stocké dans la base.

Les 2 causes probables de votre problème:

• un jeu de caractères de la base incorrect
• ET
• un mauvais paramètrage de NLS_LANG.

Pour résoudre votre problème, il faut prendre en compte les 2 causes.

[Jinx02]

Merci pour votre réponse.

Voici :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
SQL> SELECT * FROM nls_database_parameters WHERE parameter LIKE '%SET%';
 
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_CHARACTERSET               WE8MSWIN1252
NLS_NCHAR_CHARACTERSET         AL16UTF16
 
SQL> CREATE TABLE t2(x varchar2(10));
 
Table créée.
 
SQL> INSERT INTO t2 VALUES ('é');
 
1 ligne créée.
 
SQL> SELECT * FROM t2;
 
X
----------
é
 
SQL> SELECT dump(x,1017) FROM t2;
 
DUMP(X,1017)
------------------------------------------------------------------------
Typ=1 Len=1 CharacterSet=WE8MSWIN1252: e9

Qu'en pensez-vous ?

Code :

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

1
2
 
NLS_LANG=FRENCH_FRANCE.WE8MSWIN1252

Et quand j'interroge une donnée importée :

Code :

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

1
2
3
4
5
6
7
SQL> select mon_champ from ma_table where critere=X;

champ
----------------------------------------
Cr¿pin

au lieu de Crépin

[pifor]

Dans votre 1er message on a US7ASCII comme jeu de caractères de la base source et de la base cible. Maintenant ce n'est plus le cas:
- quelles sont les véritables jeux de caractères dans les 2 bases ?
- quelle est la valeur de NLS_LANG pendant l'export et pendant l'import ?
- que donne la fonction DUMP sur la donnée dans la base source et dans la base cible ?

[Jinx02]

En effet,

j'ai recréé la base cible "normalement" et non en US7ASCII puisque le problème restait le même.

La source est donc en US7ASCII et la cible maintenant en WE8MSWIN1252.

Pendant l'export sur le serveur Unix en Oracle 8.1.7, le NLS_LANG n'est pas précisé. Il doit donc s'initialiser à AMERICAN_AMERICA.US7ASCII
Pendant l'import sur le serveur Windows 2003 en Oracle 10.2.0.4.0, le NLS_LANG est positionné à FRENCH_FRANCE.WE8MSWIN1252.

Pour les dumps :
Base source :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
SQL> CREATE TABLE t2(x varchar2(10));
 
Table created.
 
SQL> INSERT INTO t2 VALUES ('é');
 
1 row created.
 
SQL> SELECT * FROM t2;
 
X
----------
é
 
SQL> SELECT dump(x,1017) FROM t2;
 
DUMP(X,1017)
-------------------------------------
Typ=1 Len=1 CharacterSet=US7ASCII: 82

Base cible :

Code :

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

1
2
3
4
5
SQL> SELECT dump(x,1017) FROM t2;
 
DUMP(X,1017)
------------------------------------------------------------------------
Typ=1 Len=1 CharacterSet=WE8MSWIN1252: e9

Merci pour votre aide.

[pifor]

Il n'y a pas de caractère accentué en US7ASCII car le 7 signifie ici 7 bits.
Quand le jeu de caractère de NLS_LANG correspond à celui de la base, Oracle ne vérifie rien et la donnée est incohérente dans la base. L'affichage semble correct mais la donnée est fausse

Il n'y a pas de solution facile à ce problème: peut-être détecter par programme SQL et la fonction DUMP toutes les valeurs erronées dans toutes les tables de la base cible et faire une mise à jour.

[Jinx02]

Ce qui m'étonne le plus c'est que l'application qui utilise la base Oracle 8.1.7 sur l'Unix arrive à afficher des accents sur une base qui ne stockerait pas les caractères accentués...

[Jinx02]

En utilisant dmp2utf8, j'ai résolu le problème...