Discussion :

[Ricocmk]

Bonjour,

Je sollicite la communauté car je ne parviens pas à résoudre mon problème.

Je créé une table dans la Work contenant un champs texte qui contient un mot avec un accent. Lorsque j'envoi cette table dans une base Oracle avec une procédure SQL, puis que j'affiche cette table, l'accent n'est pas interprété.

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
 
LIBNAME FRDDTBR ORACLE  PATH=XXXXXXXX  USER=XXXXXXX  PASSWORD="{sas002}XXXXXXXXXXX" ;
 
data toto;
    test="éric";
run;
 
PROC SQL;
    drop table FRDDTBR.toto; /* si table déjà présente */
    create table FRDDTBR.toto as select * from toto;
quit;
 
proc metalib;
     omr (library = "Fraud Data Base REC" );
     select (toto);
run;

Ci-dessous la table affichée dans la Work :


Ci-dessous la table affichée dans la base Oracle:


Ci-dessous le résultat de la procédure suivante :

Code :

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

1
2
3
4
5
 
proc sql;
	select * from FRDDTBR.nls_session_parameters;
	select * from FRDDTBR.nls_database_parameters;
quit;

Le fichier sasv9_usermods.cfg contient l'option : -locale = Frenche_France .

Je ne peux pas me permettre de modifier les fichiers de config car il y a énormément de traitements déjà en place qui utilisent des bases Oracle. Nous ne pouvons mesurer l'impact potentiel d'une modification. La seule piste que je possède actuellement est celle de SAS/CONNECT. Pourrait-on faire appel à un autre fichier de config dans la session ? ?

Je précise que le programme sera exécuté par des utilisateurs standards, les commandes X sont désactivées par sécurité.

J'ai essayé avec l'instruction suivante :

Code :

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

1
2
3
 
options set = NLS_LANG "French_France.we8iso8859p1";
options set = LANG "fr_FR";

Ces instructions créées 2 variables d'environnement mais lorsque je relance le traitement initial, le problème n'est pas résolu. La session SAS par défaut est en ENCODING LATIN9.

Un article datant de 2012 au lien suivant parlant d'un problème de TRANSCODING pourrait-être utile :
http://studysas.blogspot.fr/2012/02/...ngwlatin1.html

[mohamed_]

Bonjour,

Tu peux essayer de modifier l'encoding de ta table et voir ce que ça donne comme cela :

Code :

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

1
2
3
  PROC DATASETS NOLIST LIBRARY=work;
    MODIFY toto / CORRECTENCODING=ASCIIANY ;
  RUN;QUIT;

Tu peux aussi essayer avec CORRECTENCODING=UTF8.

[Ricocmk]

Merci pour la réponse apportée mais cela produit le même résultat

En parallèle j'ai essayé quelque chose :

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
30
31
32
33
34
35
 
/* creation variables d'environnement */
options set = NLS_LANG "French_France.we8iso8859p15";
options set = LANG "fr_FR";
 
options autosignon=yes sascmd="/app/sas/products/SASFoundation/9.3/sas" ;
 
rsubmit process=task1 wait=no  ;
 
	LIBNAME FRDDTBR ORACLE  PATH=XXXXXXXX  USER=XXXXXXXX  PASSWORD="{sas002}XXXXXXXXXXXXXXX" ;
 
	options set = NLS_LANG "French_France.we8iso8859p15";
	options set = LANG "fr_FR";
 
	%Put NLS_LANG = %sysget(NLS_LANG);
	%Put LANG = %sysget(LANG);
 
	data toto;
		test="éric";
	run;
 
	PROC SQL;
		drop table FRDDTBR.toto;
		create table FRDDTBR.toto as select * from toto;
	quit;
 
endrsubmit task1;
 
waitfor _all_ task1 ;
signoff task1;
 
proc metalib;
	omr (library = "Fraud Data Base REC" );
	select (toto);
run;

Résultat de la table TOTO dans Oracle après la première et la seconde exécution :


Fermeture de la session SAS puis réouverture d'une nouvelle session, affichage de la table dans Oracle sans avoir exécuté de programme :


exécution du programme suivant :

Code :

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

1
2
3
 
options set = NLS_LANG "French_France.we8iso8859p15";
options set = LANG "fr_FR";

Affichage de la table dans Oracle :


Exécution du programme suivant :

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
30
31
32
33
34
35
36
37
38
39
40
 
/* Définition variables d'environnement pour toute la durée de cette session */
options set = NLS_LANG "French_France.we8iso8859p15";
options set = LANG "fr_FR";
 
/* Création d'une session distante grâce au multi-processing */
options autosignon=yes sascmd="/app/sas/products/SASFoundation/9.3/sas -noautoexec";
 
rsubmit process=task1 log=purge wait=no ;
 
	%Put session distante actualise parametres de session ;
 
endrsubmit task1;
 
waitfor _all_ task1 ;
signoff task1;
 
/* Masquer les infos du LIBNAME */
options nosource nosource2 ;
 
LIBNAME FRDDTBR ORACLE  PATH=XXXXXXXXX  USER=XXXXXXXXXXX  PASSWORD="{sas002}XXXXXXXXXXXXXXXX" ;
 
options source source2 ;
 
%Put NLS_LANG = %sysget(NLS_LANG);
%Put LANG = %sysget(LANG);
 
data toto;
	test="éric";
run;
 
PROC SQL;
	drop table FRDDTBR.toto;
	create table FRDDTBR.toto as select * from toto;
quit;
 
proc metalib;
	omr (library = "Fraud Data Base REC" );
	select (toto);
run;

Affichage de la table dans Oracle :


Très bizarre !
A priori, SAS agirait en 2 temps :

1. Déclaration des variables d'environnement et exécution du code
2. L'intégration de ces variables se ferait grâce au changement de session qui semble "actualiser" les paramètres de la session

C'est la "solution" la plus aboutie que je possède actuellement.
S'il y a une commande permettant "d'actualiser" ces paramètres de session plutôt que d'en créer une puis de la killer, je suis preneur.