I am using the ROracle library to access an Oracle database from RStudio. Please see the code below:
drv = dbDriver("Oracle")
connect.string = paste(
"(DESCRIPTION=",
"(ADDRESS=(PROTOCOL=tcp)(HOST=", host, ")(PORT=", port, "))",
"(CONNECT_DATA=(SID=", sid, ")))", sep = "")
con = dbConnect(drv, username = "",
password = "",dbname=connect.string, encoding="latin1")
### Pull tables
keyword = dbGetQuery(con, "select COLUMN1,COLUMN2 from TABLE1")
In my column i got the words: Lørdag, søndag etc which is returned as: L?rdag, S?ndag.
R Session Info:
R version 3.4.2 (2017-09-28)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)
Matrix products: default
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C LC_TIME=English_United States.1252
attached base packages:
[1] parallel stats graphics grDevices utils datasets methods base
other attached packages:
[1] stringi_1.1.5 doParallel_1.0.11 iterators_1.0.8 ROracle_1.3-1 DBI_0.7 foreach_1.4.3
loaded via a namespace (and not attached):
[1] compiler_3.4.2 tools_3.4.2 codetools_0.2-15
Finally works! Apparently i couldnt find any way to force encoding in my code. However, i added the environment variable "NLS_LANG" and the corresponding langauge code to my operating system which fixed the issue
Related
I know it has been adressed several times, but despite many investigations and tries, I have been unabled to solve it so far.
Basically, Rmarkdown fails to render cyrillic characters where there are evaluated in inline code:
---
title: "My Title"
output: html_document
---
### Заказчик
### `r "Заказчик"`
### `r knitr::asis_output("Заказчик")`
produces
My session info is :
> sessionInfo()
R version 4.1.0 (2021-05-18)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19043)
Matrix products: default
locale:
[1] LC_COLLATE=French_France.1252 LC_CTYPE=French_France.1252 LC_MONETARY=French_France.1252 LC_NUMERIC=C
[5] LC_TIME=French_France.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.1.0 fastmap_1.1.0 htmltools_0.5.2 tools_4.1.0 yaml_2.2.1 rmarkdown_2.11 knitr_1.34 xfun_0.26
[9] digest_0.6.28 rlang_0.4.11 evaluate_0.14
Any suggestion ?
Your code works nice.
For the future, create a Rmd-file in the utf-8 encoding.
If you forgot to do that - use "file - > reopen with encoding".
Also, you can use enc2utf8
### Заказчик
### `r enc2utf8("Заказчик")`
### `r knitr::asis_output("Заказчик")`
My session info:
R version 4.1.0 (2021-05-18)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
Matrix products: default
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
system code page: 1251
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] stringr_1.4.0 ggplot2_3.3.5 dplyr_1.0.7 kableExtra_1.3.4
[5] formattable_0.2.1
Desciption of the issue is given at link. It seems that it is a PostgreSQL bug only. To resolve this issue, there seems to be only a single workaround, which is to create a list of locale (map) with key as <Language>_<Country>.<CodePage>and value as <Language>, <Country>.
For example:
English_United States.1252 = English, United States
...
Since value of parameter --locale is accepted in the format of <Language>, <Country>whereas output of command SHOW LC_COLLATE is in the format of <Language>_<Country>.<CodePage>. So, during an ugrade I will get the value of lc_collate cmd and get the corresponding value from the list and provide it during PostgreSQL 9.5 installation.
How do I convert <Language>_<Country>.<CodePage> to appropriate format for successful installation ?
After an upgrade from Ubuntu Server 14.04 to 16.04 I had to also upgrade my Postgres clusters from 9.3 to 9.5. The normal way to do that is to first drop the (empty) 9.5 cluster that the upgrade created:
# pg_dropcluster 9.5 main
and then to upgrade the old 9.3 cluster to 9.5:
# pg_upgradecluster 9.3 main
This however results in an error:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US.UTF-8",
LC_ALL = (unset),
LC_PAPER = "nl_NL.UTF-8",
LC_ADDRESS = "nl_NL.UTF-8",
LC_MONETARY = "nl_NL.UTF-8",
LC_NUMERIC = "nl_NL.UTF-8",
LC_TELEPHONE = "nl_NL.UTF-8",
LC_IDENTIFICATION = "nl_NL.UTF-8",
LC_MEASUREMENT = "nl_NL.UTF-8",
LC_TIME = "nl_NL.UTF-8",
LC_NAME = "nl_NL.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
Error: The locale requested by the environment is invalid.
Error: Could not create target cluster
This means I could not upgrade to Postgres 9.5.
I checked all locale settings:
the en_US.UTF-8 locale exists and is properly generated as checked with locale -a (it shows en_US.utf8 in its list)
The file /etc/environment contains LC_ALL=en_US.UTF-8 and LANG=en_US.UTF-8
/etc/default/locale contains the same setting for LANG, LANGUAGE and LC_ALL
I can start Perl without any issue using "perl -e exit"
The error message is generated from the pg_createcluster script which is called from pg_updatecluster. But running pg_createcluster from the command line works just fine, without any issue.
Workaround for the issue:
I used the following workaround to at least get the conversion to work. I edited the /usr/bin/pg_upgradecluster script, as follows:
Find the code where it calls pg_createcluster by looking for the comment "create new cluster"
That code consists of a series of "push" statements, ending in the suspicious line:
delete $ENV{'LC_ALL'}
Notice that this LC_ALL is exactly the variable that is unset in the error message.
Comment out that delete comment by adding a '#' before it, then save.
This at least circumvents this problem and lets you run the upgrade.
My question: is this a bug in the pg_upgradecluster script, or is something else awry on my system?
had the same problem on an ubuntu 16.04 server. what helped in my case was to generate all the locales that appear in your listing of $ locale:
$ sudo locale-gen "en_US.UTF-8"
$ sudo locale-gen "nl_NL.UTF-8"
good luck!
In my case, it was complaining about
Error: The locale requested by the environment is invalid:
LANG: en_GB
LANGUAGE: en_GB:en
So I unset LANG and unset LANGUAGE and it worked.
For me, I have followed many suggestions and still didn't work.
The script mentioned
LC_TIME=en_UK but it's totally unrelated so I ignored it at first.
Turns out this was the problem and doing "unset LC_TIME" was all I needed.
Posting here in case it happened to someone else.
My quick way to disable that message: (macOS 12 Monterey M1)
Open Terminal -> Preferences -> Advanced tab -> uncheck to Set locale environment variables on startup
Just came across this in fresh Ubuntu + PostgresQL install, after all those years.. either way, the solution is:
apt-get install locales
I have installed unixOdbc on my Ubuntu PC.
I have configured DSN 'mydsn' and it works just fine with isql.
> isql mydsn
+---------------------------------------+
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
+---------------------------------------+
SQL> insert into users values('1', 'user', 'password');
SQLRowCount returns 1
It means postgres odbc driver and data source are installed and configured properly. I couldn't connect isql before everything was configured.
If I am trying to execute the same statement with Poco::ODBC it fails with the exception.
E [2016-06-25 13:41:48.117] Application {3}: ODBC handle exception: SQLCloseCursor(): Connection:Not applicable
Server:Not applicable
===========================
ODBC Diagnostic record #1:
===========================
SQLSTATE = 200
Native Error Code = 0
[nxDC[rvrMngrIvldcro tt
Here is my code
using Poco::Data::ODBC::Connector;
...
Connector::registerConnector();
_pool = new SessionPool(Connector::KEY, "DSN=mydsn;", size, size);
Session session(_pool->get());
session << "insert into users values('2', 'user', 'password');", now;
I tried to google SQLCloseCursor exception but it gives me a lot of irrelevant results. I haven't tried to debug (break points and so) this yet.
Any suggestion of where to start?
I have upgrade ubuntu 14 to ubuntu 16.04 and the problem disapperd. It looks like some bug in unixODBC 2.24 while working with Postgres 9.3.
Could anybody give an insight on the locale and numeric types behaviour in PostgreSQL? We work with Italian locale. That is comma separation for decimal part. Setting in postgresql.conf
# These settings are initialized by initdb, but they can be changed.
lc_messages = 'it_IT.UTF-8' # locale for system error message
# strings
lc_monetary = 'it_IT.UTF-8' # locale for monetary formatting
lc_numeric = 'it_IT.UTF-8' # locale for number formatting
lc_time = 'it_IT.UTF-8' # locale for time formatting
.. does nothing! It behaves in a quite appropriate way with dates and so, BUT the numeric type remains DOT separated for decimal part.
root#server:~# uname -a
Linux server 2.6.32-36-generic-pae #79-Ubuntu SMP Tue Nov 8 23:25:26 UTC 2011 i686 GNU/Linux
root#server:~# dpkg -l | grep postgresql
ii postgresql-8.4 8.4.9-0ubuntu0.10.04 object-relational SQL database, version 8.4
ii postgresql-client 8.4.9-0ubuntu0.10.04 front-end programs for PostgreSQL (supported)
EDIT
Having problem with implementation of locale in different scopes: db, server script, os and client side. Decided to avoid any locale formatting and use en_EN locale. The locale formatting will be applied only at the moment of output and so.
I quote the manual:
lc_numeric (string)
Sets the locale to use for formatting numbers, for example with the to_char family of functions.
Concerns these type formatting functions. You should be able to reproduce the following demo:
SHOW lc_numeric;
de_AT.UTF-8
SELECT to_number('13,4','999D99')
13.4
SELECT to_char(13.4,'FM999D99')
13,4
SET lc_numeric = 'C';
SELECT to_number('13,4','999D99')
134
SELECT to_char(13.4,'FM999D99')
13.4
RESET lc_numeric;
Template patterns in the manual.
The format of numbers in SQL expressions does not change with locale settings. That would be madness.
On a different note: you are aware that you have to (at least) reload the server after changing postgresql.conf.
pg_ctl reload