RODBC sur une base Oracle et caractères spéciaux
Bonjour,
Je viens vers vous car j'ai un comportement que je n'arrive pas à comprendre lors d'une requête sur une base Oracle, via RODBC dans R.
R convertit automatiquement (quand il y arrive) les caractères spéciaux en caractères "simples".
Voici un petit test très simple que j'ai fait et le résultat obtenu :
Code:
1
2
3
4
| > Cnx <- odbcConnect(dsn="monDatasource", uid="monLogin",pwd="monMotDePasse")
> sqlQuery(Cnx, paste("SELECT 'eéèêëÄÊÍÕØ' col FROM DUAL"))
COL
1 eeeeeAEI?? |
Je suis sur un Windows 7 x64. "monDatasource" est une source de données ODBC qui utilise le pilote "Oracle dans OraClient12home1" (pilote 64 bits). J'utilise R x64 3.2.0 avec le Package RODBC version 1.3-11.
J'ai fait pas mal d'autres tests pour comprendre :
- Même test avec une source ODBC qui utilise le pilote "Oracle dans OraClient12home1_32bit" dans R i386 3.2.0 => Même problème
- Même test avec une source ODBC SQL server => Là, ça marche, les caractères ne sont pas convertis
- Utilisation de la connexion ODBC dans Excel avec la même requête => Là aussi ça marche, dans ma cellule Excel j'ai bien les caractères spéciaux
Le plus fou c'est que j'ai installé le pilote "Oracle dans OraClient12home1_32bit" sur le Windows 7 32 bit d'un collègue et depuis mon intervention, il voit les accents alors qu'avant il ne les voyait pas...
Merci de votre aide
[EDIT]
Petite précision supplémentaire, mon poste est en Windows et le serveur qui héberge la base Oracle est en Linux.
Ça a peut-être son importance d'après ce que je lis dans la documentation du package RODBC :
Citation:
6 Internationalization Issues
Internationalization issues are made more complex by ODBC being a client-server system,and the ODBC client (RODBC) and the server may be running on different machines with different OSes on different continents. [...] The other internationalization issue is the character encoding used. When R and the DBMS are running on the same machine this is unlikely to be an issue, and in many cases the ODBC driver has some options to translate character sets. SQL is an ANSI (US) standard, and DBMSs tended to assume that character data was ASCII or perhaps 8-bit. More recently DBMSs have started to (optionally or by default) to store data in Unicode, which unfortunately means UCS-2 on Windows and UTF-8 elsewhere. So cross-OS solutions are not guaranteed to work, but most do.Encoding issues are best resolved in the ODBC driver or in DBMS settings. In the unusual case that this cannot be done, the DBMSencoding argument to odbcDriverConnect allows for recoding when sending data to or from the ODBC driver and thence the DBMS.
