[8,9i][UNIX/WIN] Le Mystère des Characters set dans les CLOB

**opinette** · 13/04/2006, 18h59

Bonjour,

J'ai des problèmes de caractères accentués dans des champs de type CLOG! et je recherche de l'aide pour trouver une explication aux phénomènes que j'observe sans comprendre

Mon environnement :
- Serveur Oracle 9i sous UNIX (initialement sous Oracle 8 mais migré récemment en 9i)
- Client Oracle 9i sous Windows

Pour info :

NLS_LANGUAGE = AMERICAN
NLS_CHARACTERSET = WE8MSWIN1252
NLS_NCHAR_CHARACTERSET = AL16UTF16
NLS_SAVED_NCHAR_CS = WE8MSWIN1252
NLS_NCHAR_CONV_EXCP = FALSE

Il y a un an la table suivante a été créée (à l’époque sous Oracle 8 et vraisemblablement avec un jeu de caractères différent, mais je ne sais pas lequel)

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE GraphSeries (
	ItemId				NUMBER (12)	 NOT NULL ,
…
	DataBaseID			NUMBER (12) NULL ,
	EquationOrFilter	CLOB NULL , 
	IsPrimaryX			NUMBER (5) DEFAULT 0 NOT NULL ,
…
	Permissions		VARCHAR2 (500) NULL , 
	PRIMARY KEY ( ItemId ) ) ;

Quelques jours après la création de cette table le jeu de caractères de la base a été changé pour aboutir à la configuration d’aujourd’hui.

Puis la table a été peuplée. Elle est peuplée via une application .NET pour lequel je n’ai pas de détail.
Via l’application en question je remplis notamment le champ EquationOrFilter qui est de type CLOB et qui me pose problème. Certain des enregistrements comportent des caractères accentués.

Par example

Code :

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

select ItemId,EquationorFilter from GRAPHSERIES where Itemid=9614;

donne:

Code :

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

1
2
3
   ITEMID EQUATIONORFILTER
---------- --------------------------------------------------------------------------------
      9614 ééàà

Ce résultat me convient : j’obtiens bien ce que j’ai saisi via mon application.

Le problème commence lorsque je passe la commande suivante:

Code :

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

1
2
3
4
5
declare o CLOB;
BEGIN
select EQUATIONORFILTER into o from GRAPHSERIES where Itemid=9614;
END;
/

car le résultat est :

Code :

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

1
2
3
4
5
ERREUR à la ligne 3 :
ORA-06550: line 3, column 8:
PL/SQL: ORA-12704: character set mismatch
ORA-06550: line 3, column 1:
PL/SQL: SQL Statement ignored

Mon premier problème est que je ne comprends pas pourquoi j’ai ce message d’erreur.

Passons au second problème :

Si je lance la commande

Code :

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

UPDATE GRAPHSERIES SET EQUATIONORFILTER= 'abcàéè' where Itemid=9614;

Puis

Code :

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

select ItemId,EquationorFilter from GRAPHSERIES where Itemid=9614;

Le résultat est :

Code :

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

1
2
3
    ITEMID EQUATIONORFILTER
---------- --------------------------------------------------------------------------------
      9614 abcaee

Je n’ai pas mes accents !!

Pourquoi ?

Je passe alors à mon 3eme problème :
J’ai recréé une autre table sur le même modèle

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE opi (
	ItemId				NUMBER (12)	 NOT NULL ,
…
	DataBaseID			NUMBER (12) NULL ,
	EquationOrFilter	CLOB NULL , 
	IsPrimaryX			NUMBER (5) DEFAULT 0 NOT NULL ,
…
	Permissions		VARCHAR2 (500) NULL , 
	PRIMARY KEY ( ItemId ) ) ;

J’ai ajouté un enregistrement, puis j’ai effectué les mêmes manipulation :

Code :

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

UPDATE opi SET EQUATIONORFILTER= 'abcàéè' where Itemid=1;

Puis

Code :

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

select ItemId,EQUATIONORFILTER from opi where Itemid=1;

Résultat:

Code :

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

1
2
3
    ITEMID EQUATIONORFILTER
---------- --------------------------------------------------------------------------------
         1 abcàéè

Là j’ai bien mes accents!
Pourquoi dans le cas précédent je n’ai pas mes accents alors que là je les ai !

La seul différence entre les 2 tables (enfin pour moi) c’est que la première à été créé sous Oracle 8 et avec un jeu de caractère qui à l’époque était différent.

**LeoAnderson** · 13/04/2006, 21h04

tout d'abord, merci de rajouter les balises de code ! ;-)

Sinon, vous dites que le jeu de caractères a été changé ?
C'est bien, mais il faudrait le avant/après ainsi que le moyen pour passer de l'un à l'autre...

**pifor** · 13/04/2006, 21h04

Pouvez-vous nous donner le résultat de la requête suivante dans la session où vous détectez les problèmes:

Code :

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

1
2
 
SELECT * FROM nls_session_parameters

Et la valeur de la variable d'environnement NLS_LANG pour la même session:
- sous UNIX:

Code :

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

1
2
 
 echo $NLS_LANG

- sous Windows, depuis sqlplus:

Code :

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

1
2
 
@[.%NLS_LANG%]

Est-ce que tous les problèmes sont détectés dans le même environnement sqlplus (depuis le même OS, avec la même valeur pour NLS_LANG) ?

Merci d'utiliser les balises pour meilleure lisibilité

**opinette** · 13/04/2006, 22h23

Envoyé par LeoAnderson

tout d'abord, merci de rajouter les balises de code ! ;-)

Sinon, vous dites que le jeu de caractères a été changé ?
C'est bien, mais il faudrait le avant/après ainsi que le moyen pour passer de l'un à l'autre...

Voila je viens d'ajouter les balises...

Pour répondre à la question, hélas je n'ai pas de trace du "avant".
Et encore moins du moyen utilisé pour changer le jeu de caracteres

**opinette** · 14/04/2006, 10h46

Envoyé par pifor

Pouvez-vous nous donner le résultat de la requête suivante dans la session où vous détectez les problèmes:

Voici les resultats sous SQL/Plus Windows:

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
SELECT * FROM nls_session_parameters
 
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE                   FRENCH
NLS_TERRITORY                  FRANCE
NLS_CURRENCY                   €
NLS_ISO_CURRENCY               FRANCE
NLS_NUMERIC_CHARACTERS         ,.
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD/MM/RR
NLS_DATE_LANGUAGE              FRENCH
NLS_SORT                       FRENCH
NLS_TIME_FORMAT                HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT           DD/MM/RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT             HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT        DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY              €
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE

Et la valeur de la variable d'environnement NLS_LANG pour le login qui lance les daemons Oracle:
- sous UNIX:

Code :

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

1
2
echo $NLS_LANG
Rien

En fait aucune variable NLS_* n'est definie.

- sous Windows, depuis sqlplus:

Code :

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

1
2
@[.%NLS_LANG%]
SP2-0310: impossible d'ouvrir le fichier "[.FRENCH_FRANCE.WE8MSWIN1252]"

Envoyé par pifor

Est-ce que tous les problèmes sont détectés dans le même environnement sqlplus (depuis le même OS, avec la même valeur pour NLS_LANG) ?

Oui je n'utilise que le client Windows et je fais mes manips sous SQL*Plus Worksheet

**pifor** · 14/04/2006, 10h57

Merci. Je n'arrive pas à reproduire le problème 1 ...

Je voudrais aussi avoir le résultat de

Code :

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

1
2
 
select * from nls_database_parameters;

**LeoAnderson** · 14/04/2006, 10h58

Le problème commence lorsque je passe la commande suivante:

Code :

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

1
2
3
4
5
declare o CLOB;
BEGIN
select EQUATIONORFILTER into o from GRAPHSERIES where Itemid=9614;
END;
/

Si vous déclarez votre variable o en NCLOB? ça donne quoi ?

**opinette** · 14/04/2006, 11h12

Envoyé par LeoAnderson

Si vous déclarez votre variable o en NCLOB? ça donne quoi ?

Avec un NCLOB, c'est à dire

Code :

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

1
2
3
4
5
declare o NCLOB;
BEGIN
select EQUATIONORFILTER into o from GRAPHSERIES where Itemid=9614;
END;
/

J'obtiens exactement le même message d'erreur

**pifor** · 14/04/2006, 13h10

Est-ce que vous être sûre de la description de la table GRAPHSERIES ?
Car les problèmes 1 et 2 pourraient venir du fait que le jeu de caractères utilisé par le stockage est différent de celui de la base; peut-être que la colonne EQUATIONORFILTER est de type NCLOB et non CLOB ?

Le problème 3 n'est en fait pas un problème, il correspond au fonctionnement normal d'un CLOB lorsque le jeu de caractères NLS_LANG du client correspond à celui de la base; le comportement d'un CLOB par rapport au jeu de caractères est en principe le même qu'avec un VARCHAR2.

Vous pouvez comparer la représentation physique des colonnes EQUATIONORFILTER avec la fonction dump:

Code :

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

1
2
 
select dump(to_char(EQUATIONORFILTER))  from ... where ...

**opinette** · 14/04/2006, 13h24

Voici le resultat de la demande de pifor

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
28
select * from nls_database_parameters;
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               WE8MSWIN1252
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         AL16UTF16
NLS_SAVED_NCHAR_CS             WE8MSWIN1252
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_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
NLS_RDBMS_VERSION              9.2.0.1.0

**opinette** · 14/04/2006, 13h37

Envoyé par pifor

Est-ce que vous être sûre de la description de la table GRAPHSERIES ?
Car les problèmes 1 et 2 pourraient venir du fait que le jeu de caractères utilisé par le stockage est différent de celui de la base; peut-être que la colonne EQUATIONORFILTER est de type NCLOB et non CLOB ?

Oui je suis certain, car j'ai le script qui a créé la table et j'ai également vérifier sa définition actuelle: c'est bien un CLOB

Envoyé par pifor

Le problème 3 n'est en fait pas un problème, il correspond au fonctionnement normal d'un CLOB lorsque le jeu de caractères NLS_LANG du client correspond à celui de la base; le comportement d'un CLOB par rapport au jeu de caractères est en principe le même qu'avec un VARCHAR2.

Si je comprends bien ma table GRAPHSERIES utiliserait l'ancien jeu de caractères. Alors que ma table OPI utiliserait le nouveau.
Pourtant ma table à été peuplée après le changement de jeu de caractères, Donc si je comprends bien le jeu de caractères utilisé n'est pas celui défini au moment ou les données sont entrées mais le jeu de caractères au moment où la table est créée.
Est-ce bien cela?

Enfin voici le dump:

Code :

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

1
2
3
4
5
 
select dump(to_char(EQUATIONORFILTER)) from GRAPHSERIES where Itemid=9614;
DUMP(TO_CHAR(EQUATIONORFILTER))
 
Typ=1 Len=6: 97,98,99,97,101,101

Il faut donc arriver à trouver à quel jeu de caractères cela correspond.
(Cela risque de correspondre à plusieurs !)

**opinette** · 14/04/2006, 13h51

J'ai ensuite recréé ma chaine de caractères "abcàéè" via mon application:
Puis vérifier le résultat et le dump:

Code :

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

1
2
3
4
5
6
7
8
9
select EQUATIONORFILTER from GRAPHSERIES where Itemid=9614;
EQUATIONORFILTER
--------------------------------------------------------------------------------
abcàéè
 
select dump(to_char(EQUATIONORFILTER))  from GRAPHSERIES where Itemid=9614;
DUMP(TO_CHAR(EQUATIONORFILTER))
 
Typ=1 Len=6: 97,98,99,96,105,104

Cela ne semble pas être le jeu de caractères WE8MSWIN1252

**pifor** · 14/04/2006, 13h53

Pour une colonne de type VARCHAR2 ou CLOB, le jeu de caractères utilisée par le stockage est toujours celui de la base (celui retourné par NLS_DATABASE_PARAMETERS). Là, il n'y a pas de mystère. C'est seulement pour les types NVARCHAR2, NCLOB que le "national charcater set" est utilisé, également défini au niveau de la base.

NLS_LANG est utilisé pour savoir s'il faut faire une conversion en lecture ou en écriture. Si le jeu de caractères de NLS_LANG correspond à celui de la base, Oracle ne fait aucune conversion et ne fait pas de vérification, ce qui peut poser des problèmes.

Donc si je comprends bien le jeu de caractères utilisé n'est pas celui défini au moment ou les données sont entrées mais le jeu de caractères au moment où la table est créée.
Est-ce bien cela?

le jeu de caractères utilisé pour le stockage après éventuelle conversion est celui défini dans CREATE DATABASE et celui pour afficher est éventuellement converti suivant la valeur de NLS_LANG.

Si vous comparez avec la fonction dump les colonnes CLOB des tables GRAPHSERIES et OPI, est-ce que vous avez la même chose ?

**opinette** · 14/04/2006, 14h04

Envoyé par pifor

Le problème 3 n'est en fait pas un problème, il correspond au fonctionnement normal d'un CLOB lorsque le jeu de caractères NLS_LANG du client correspond à celui de la base; le comportement d'un CLOB par rapport au jeu de caractères est en principe le même qu'avec un VARCHAR2.

Je reviens sur ce point.
Dans ma table GRAPHSERIES j'ai également un champ TITLE de type VARCHAR2(75).
J'ai fait le même exercice avec ce champ, c-a-d:
Via mon application j'ai initialisé le champ Title avec la même chaine de caractères abcàéè et fait le DUMP..; et là ...:

Code :

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

1
2
3
4
5
6
7
8
9
select title from GRAPHSERIES where Itemid=9614;
TITLE
---------------------------------------------------------------------------
abcàéè
 
select dump(to_char(title)) from GRAPHSERIES where Itemid=9614;
DUMP(TO_CHAR(TITLE))
 
Typ=1 Len=6: 97,98,99,224,233,232

Le comportemment des VARCHAR2 et des CLOB et donc different dans ma base.
Car là c'est bien du WE8MSWIN1252

**opinette** · 14/04/2006, 14h12

Envoyé par pifor

Si vous comparez avec la fonction dump les colonnes CLOB des tables GRAPHSERIES et OPI, est-ce que vous avez la même chose ?

Justement pas!

Code :

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

1
2
3
4
5
6
7
select EQUATIONORFILTER,dump(to_char(EQUATIONORFILTER))  from OPI where Itemid=1;
EQUATIONORFILTER
--------------------------------------------------------------------------------
DUMP(TO_CHAR(EQUATIONORFILTER))
 
abcàéè
Typ=1 Len=6: 97,98,99,224,233,232

La chaine abcàéè
donne 97 98 99 224 233 232 dans OPI
donne 97 98 99 96 105 104 dans GRAPHSERIES

**pifor** · 14/04/2006, 14h34

Via mon application j'ai initialisé le champ Title avec la même chaine de caractères abcàéè et fait le DUMP..; et là ...:

C'est sans doute parce que la valeur de NLS_LANG n'est pas la même que votre test avec sqlplus. Pour être sûr de ce qui se passe, il faut que vous ayez la valeur complète (avec le jeu de caractères) de cette variable qui ne peut être positionnée qu'au niveau OS. S'il s'agit d'une application web, c'est l'environnement au démarrage du serveur d'application qui est pris en compte.

**opinette** · 14/04/2006, 14h50

Envoyé par pifor

Via mon application j'ai initialisé le champ Title avec la même chaine de caractères abcàéè et fait le DUMP..; et là ...:

C'est sans doute parce que la valeur de NLS_LANG n'est pas la même que votre test avec sqlplus. Pour être sûr de ce qui se passe, il faut que vous ayez la valeur complète (avec le jeu de caractères) de cette variable qui ne peut être positionnée qu'au niveau OS. S'il s'agit d'une application web, c'est l'environnement au démarrage du serveur d'application qui est pris en compte.

Je ne suis pas certain de bien comprendre votre remarque... je risque donc de repondre a coté

Dans les 2 cas (c-a-d CLOB et VARCHAR2) j'ai fait la même manip à savoir : Modifier le champ dans mon appli avec la valeur "abcàéè". Puis verifier le résultat avec sqlplus.

Enfin pour le NLS_LANG:
Je lance mon sqlplus de la même machine (PC) et du même environnememnt que mon appli, il n'y a pas de variable d'environnememnt NLS_LANG definie sur ce PC mais la rappel que

Code :

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

1
2
@[.%NLS_LANG] 
SP2-0310: impossible d'ouvrir le fichier "[.FRENCH_FRANCE.WE8MSWIN1252]"

**pifor** · 14/04/2006, 14h57

Votre application, c'est du client/serveur , du web ?
C'est une application interne, un produit ? Vous avez le code source ?
Il se peut que votre application code en dur quelque chose pour NLS_LANG. ..

Est-ce que vous avez une seule installation Oracle Net client sur votre poste ?
Est-que votre application utilise la même version d'Oracle Net que votre sqlplus ?

Sous Windows, si NLS_LANG n'est pas définie comme variable d'environnement, sa valeur est définie par le registre Windows
(cherchez la clé NLS_LANG dans le registre).

**opinette** · 14/04/2006, 15h13

Envoyé par pifor

Votre application, c'est du client/serveur , du web ?
C'est une application interne, un produit ? Vous avez le code source ?
Il se peut que votre application code en dur quelque chose pour NLS_LANG. ..

Oui, c'est du web (type .Net) et mon serveur web est sur la machine où il y a mon client oracle. C'est également là que je fais mes manips.
C'est un produit Américain.
Non, je n’ai pas le code source
Oui c'est possible qu'il y ai quelque chose dans le code, mais :
1 - je n'arrive pas à obtenir l'information de l'éditeur.
2 - si il y avait quelque chose dans le code ne devrais-je pas avoir le même comportement pour les champs VARCHAR2 et CLOB?

Envoyé par pifor

Est-ce que vous avez une seule installation Oracle Net client sur votre poste ?
Est-que votre application utilise la même version d'Oracle Net que votre sqlplus ?

Pour parler franchement là je ne sais pas!
Je pense que l'application n'utilise pas Oracle net (mais je ne maitrise pas ce qu'est Oracle Net).
A l'installation de mon application je dois définir une chaine de connexion du genre :

Code :

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

dbtype=ORACLE8;data source=ORCL;USER=uu;PWD=xxx;

Envoyé par pifor

Sous Windows, si NLS_LANG n'est pas définie comme variable d'environnement, sa valeur est définie par le registre Windows
(cherchez la clé NLS_LANG dans le registre).

Je confirme dans la registry il y a bien

Code :

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

NLS_LANG=FRENCH_FRANCE.WE8MSWIN1252

**pifor** · 14/04/2006, 15h35

2 - si il y avait quelque chose dans le code ne devrais-je pas avoir le même comportement pour les champs VARCHAR2 et CLOB?

Difficile à dire: ce qui est sûr, c'est que pour Oracle, le traitement des VARCHAR2 et des CLOB par rapport au jeu de caractères est le même. A priori, s'il y a une différence systématique elle est ailleurs.

Je pense que l'application n'utilise pas Oracle net (mais je ne maitrise pas ce qu'est Oracle Net).

Oracle Net c'est le code Oracle côté client et serveur qui est utilisé pour se connecter à Oracle: toute application l'utilise. Dans une application web, le client de la base de données, c'est le serveur web. Je ne connais pas assez Windows et .Net mais il serait intéressant de savoir si le serveur web prend la configuration NLS_LANG du registre ou une autre (dans un script de démarrage ou dans une autre partie du registre ?).

Si vous n'avez qu'une seule clé NLS_LANG dans le registre, ça vaut dire qu'il n'y a qu'une seule installation de Oracle Net.

[8,9i][UNIX/WIN] Le Mystère des Characters set dans les CLOB

Oracle

Vue hybride

Discussions similaires

Partager

Partager