Discussion :

[qadddd]

Bonjour.

Voila mon problème:
En utilisant ProC, j'aimerais stocker dans ma base Oracle 10g des caracteres UTF8 Koreens et les retrouver, mais je n'y arrive pas, ce que je stocke se trouve altéré (une conversion implicite ou je ne sais quoi).
Ma base est déclarée de la façon suivante:

------------------------------------------
| NLS_NCHAR_CHARACTERSET | UTF8 |
| NLS_LANGUAGE | AMERICAN |
| NLS_TERRITORY | AMERICA |
| NLS_CURRENCY | $ |
| NLS_ISO_CURRENCY | AMERICA |
| NLS_NUMERIC_CHARACTERS | ., |
| NLS_CHARACTERSET | UTF8 |
| NLS_CALENDAR | GREGORIAN |
| NLS_DATE_FORMAT | DD-MON-RR |

etc etc

Ma table de test TABTEST est définie de la façon suivante:

----------------------------------------------------------
TestID INTEGER,
TestValue VARCHAR2(12)
TestValue2 NVARCHAR2(12)

Voici un extrait du code C que j'utilise pour faire mon INSERT et mon SELECT:

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
29
-----------------------------------------------------------------------------
 
/*Je simule une string contenant 1 caractere Koreen UTF8 qui vaut 
44032 en dec, 
AC00 en UTF16 
ou EAB080 sur 3 octets en UTF8*/
FbChar_t MyUTF3[4];
MyUTF3[0]=0xEA;
MyUTF3[1]=0xB0;
MyUTF3[2]=0x80;
MyUTF3[3]='\0';
printf ("Following value will be inserted in DB /%s/\n", MyUTF3);
/* sur xterm -u8 mon caractere Koreen s'affiche correctement lors de l'execution*/
/* Code ProC pour faire mon insert */ 
EXEC SQL AT FQMF INSERT INTO TabTest (TestID, TestValue, TestValue2) VALUES (3, :MyUTF3, :MyUTF3);
 
-----
 
/* Code ProC pour faire mon select */
FbChar_t MyCharBack3[21] = "....";
FbChar_t MyCharBack23[21] = "....";
memset(&MyCharBack3, '\0', 21);
memset(&MyCharBack23, '\0', 21);
EXEC SQL AT FQMF
   DECLARE C_GetData_Main3 CURSOR FOR 
       select  MyTab.TESTVALUE,MyTab.TESTVALUE2 from TABTEST MyTab where MyTab.TESTID=3;     
EXEC SQL OPEN C_GetData_Main3;
EXEC SQL FETCH C_GetData_Main3 INTO :MyCharBack3,:MyCharBack23;
printf ("Retrieved value3 from DB is/%s/%s/\n", MyCharBack3,MyCharBack23);

Resultat de l'execution:

------------------------
Following value will be inserted in DB /가/
Retrieved value3 from DB is/???/???/

Note: le caractere bizarre entre les 2 slashs est le fameux caractere Koreen correctement affiche sur xterm -u8
et les caracteres recuperes sont devenus 3 points d'interrogation.

Vérification du contenu de la base oracle a l'aide de Toad:

----------------------------------------------------------
La visualisation des datas sous Toad ne me montre que des "¿¿¿"...
Si je fais un: select dump(TESTVALUE) from TABTEST where TESTID=3;
ca donne: Typ=1 Len=9: 239,191,189,239,191,189,239,191,189
C'est a dire 3 caracteres UTF8 correspondant au caractere "¿"

Note: la seule façon que j'ai trouvée pour stocker correctement mon caractère Koreen sous Oracle est de le faire sous Toad, en faisant un:
insert into TABTEST (TESTID,TESTVALUE) values (0,unistr('\AC00'));
La visualisation des datas sous Toad montre un "¿"...
mais select dump(TESTVALUE) from TABTEST where TESTID=0;
donne : Typ=1 Len=3: 234,176,128
ce qui correspond bien a la représentation UTF8 de mon caractère ....
Mais impossible de le faire via ProC

Alors si quelqu'un a déjà été confronte a ce genre de sujet, peut-il me donner quelques infos sur la façon de faire.

D'avance Merci

Didier

[mnitu]

Avez vous lu cette article ?
C'est quoi la valeur de la variable NLS_LANG utilisé par votre application Pro*C pendant sa exécution ?

[qadddd]

Hello

Non, je n'avais pas trouve cette note en faisant mes recherches.
Je ne sais pas comment déterminer la valeur de mon NLS_LANG pendant l'exécution de mon code Pro*c.
Je n'ai aucune variable NLS_xxx valorisées dans mon shell ou autre.
Par contre, de mon xterm -u8, si je valorise une variable NLS_LANG avec AMERICAN_AMERICA.UTF8 (histoire de me retrouver avec les mêmes settings que la base Oracle) et que je lance cette exécution, le caractère Koréen est maintenant correctement inséré dans la base (en format utf8 et on y retrouve la valeur des 3 octets que j'avais dans ma string au départ), il peut également y être relu pas dégradation pour être a nouveau affiché.
C'est donc un grand pas en avant.
Merci de l'info.
Didier

[mnitu]

Du ce point de vue, votre PRO*C n'est qu'un client comme autre (sqlplus) qui se connecte à la base.
La valeur du paramètre NLS_LANG dans votre cas vient de l'environnement qui exécute le programme Pro*C (il faut bien que quelqu'un ou quelque chose exécute le programme, non ?).

[qadddd]

Nous sommes d'accord.