I want to deal UTF-8 format data using AgensGraph under Windows operation system.
AgensGraph is based on Postgres. Therefore I think that if I declare the LC_COLLATE of database as 'en_US.utf8', then I'll be able to deal UTF-8 format data.
e.g.CREATE DATABASE DBname LC_COLLATE 'en_US.utf8';
However I faced the error code.
ERROR: invalid locale name: "en_US.utf8"
So how can I know, what locale will be declared under Windows operation system?
Related
I have an issue regarding configuring Thai language in oracle (PL/SQL Developer). I have configured Thai language 'AMERICAN_AMERICA.TH8TISASCII' in regedit. Also I configured Environment variables in my computer. But still when I connect PL/SQL developer and retrieve data, columns that should show Thai descriptions are showing garbage data. Please help me.
Example of garbage data is '¿¿¿¿¿¿¿¿'
Oracle Configurations is as below :
regedit->computer->HKEY_LOCAL_MACHINE->SOFTWARE->ORACLE->KEY_OraDB11g_home1
Windown Configuration is as below:
Mycomputer->Advanced system setting->Advanced System
Settings->Environment Variables -> (here i added variable)
the same configuration is done by my peers and they got the configuration but i am not able to do this
I have configured Thai language 'AMERICAN_AMERICA.TH8TISASCII' in regedit.
It means you have configured your NLS_LANGUAGE as AMERICAN and NLS_TERRITORY as AMERICA. Which is wrong.
You should select the following:
NLS_LANGAUGE=THAI
NLS_TERRITORY=THAILAND
You need to do this at:
Database level - init.ora file
Environment level - NLS LANG settings
I think your characterset is fine.
UPDATE OP got the issue with PL/SQL Developer tool.
You can enter "alter session" commands in the AfterConnect.sql file in the PL/SQL Developer installation directory. For example:
alter session set nls_date_format='dd-mm-yyyy';
alter session set nls_territory='THAILAND';
alter session set nls_language='THAI';
source
I assume your selected font in PL/SQL Developer does not support Thai characters. Try this command to check:
SELECT UNISTR('Kho Khuat: \0E03') FROM DUAL;
Do you get proper output like this?
Kho Khuat: ฃ
If not, you should select a font which support Thai characters.
You can use this page FileFormat.info to check which font supports your character.
Value for NLS_LANG should match your local environment settings, not the setting from Database. By this all characters are properly translated in SQL communication.
Check you local environment with this command:
c:\>reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage /v ACP
In my case it is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage
ACP REG_SZ 1252
So, my NLS_LANG should be set to .WE8MSWIN1252 or something similar.
However, this is only valid if your application (SQL Developer in your case) uses the default encoding settings from Windows. In some applications you can change that - typically you can switch between local codepage and Unicode (UTF-8). In this case you must modify NLS_LANG accordingly.
I have a strange problem where in the DEV environment everything is fine but in PROD SSIS reports an error about conversion from unicode to non-unicode. This error happens at the OLE DB Source task level. So, I don't even get the chance to use Derived Columns to perform the conversion.
We installed BIDS on the production server and the task is flagged as in error. When I try to open the properties, it tells me that the metadata is different from what is in the DTSX file. When I accept the offer to automatically correct, all faulty columns input type (External and output columns) have their type switch from DT_WSTR to DT_STR.
The descriptions of the tables involved are identical in DEV and PROD (same types for the columns). If I query for the character sets they are identical in both environment.
For your information, here is the query:
SELECT *
FROM v$nls_parameters
where parameter
like '%CHARACTERSET'
which returns:
NLS_CHARACTERSET WE8MSWIN1252
NLS_NCHAR_CHARACTERSET AL16UTF16
on both environment.
Any idea to solve this ?
Thank you,
Michel
You are likely running into a difference in the drivers installed/configured on the different machines.
I ran into a similar issue with MySQL Drivers a long while back. Version X.Y.Z.13 was developed against. Server got driver version X.Y.Z.14 and boom, invalid metadata.
You will want to examine the Dev and prod server version of metadata and determine which one is right for you. In my case, the Dev driver produced varchar (non-unicode) strings and that aligned with the target system whereas the newer driver they had installed in prod deduced they should have been nvarchar (unicode) strings. Reworking the nvarchar to varchar or changing the tables was outside of the allowable timeframe for the project and the insane rules the data management team used for table creation.
According to the site,
http://www.dba-oracle.com/t_nls_lang.htm
Problem might occur even if both the database and the client use the same characterset(AL32UTF8). I couldn't understand how this can be possible.
Quoting from the site:
For example, suppose that the database character set is AL32UTF8, the
client is an English Windows operating system, and the NLS_LANG
setting on the client is AL32UTF8. Data coming into the database is
encoded in WE8MSWIN1252 and is not converted to AL32UTF8 data
because the NLS_LANG setting on the client matches the database
character set. Thus Oracle assumes that no conversion is necessary,
and invalid data is entered into the database.
How can the data be coming as WE8MSIN1252 into the database when the encoding in the client is AL32UTF8?.
Because OS itself using other character set (WE8MSIN1252 in this case). But since NLS_LANG (on client) is set to AL32UTF8, Oracle does not know about this. Oracle always uses value in NLS_LANG and ignores system settings, while (almost) all other software uses OS settings.
So, to fix this problem, local (client) NLS_LANG must be the same as OS character set. Or (other option) software running on client must reencode characters by itself.
I want to import data from a DB2 database into MS Access via ODBC. The connection is set up and working but decimal values get converted due to some locale issue (German Windows).
234.75 ends up as 23475 in the Access table.
I had the same issue with Oracle but was able to fix it by setting the ODBC drive to US locale. How can I do that with the DB2 ODBC driver?
DB2 v9.5
Do you have the possibility to read some of your field's properties through your ODBC connection? In this case I guess you could find that some of these properties will help you identify field's type, default value, length, etc. It should be then possible for you to incorporate in your import code some conversion instructions for numbers.
Have you tried to change your windows locale settings to US (start/Settings/Control Panel/Regional and language Settings/Regional Settings/customize)?
Even if your windows is german, you can set things such as decimal separator, date, etc to other standards (meaning for example that you can specificaly declare '.' as decimal separator instead of ',' for all windows applications.
When you set an ODBC connection with the linked table manager and you click through all the screens about database name, what credentials to use, there is a checkbox there for "Use regional settings when outputting dates, times, etc... something like that..." Is that checked?
Though this is an old posting some people might benefit from the solution to this issue (which I also encountered). The solution is:
Start the ODBC Administrator
Open the DSN
Open tab page Advanced
Setting Add a line with the following specs:
CLI Parameter: Patch2
Value: 15
This tells the DB2 client to use '.' as a decimal separator in stead of the locale.
Tested on: DB2 V9.7, Access 2010
Source: http://www-01.ibm.com/support/knowledgecenter/#!/SSEPGG_9.7.0/com.ibm.db2.luw.apdv.cli.doc/doc/r0008805.html
I am using the thin Oracle JDBC driver ver 10.2.0 (ojdbc14.jar). I would like to configure its NLS_LANG setting manually. Is there a way?
Currently it fetches this setting from the VM variable user.language (which is set automatically by setting the current locale, or on startup from the system environment).
This is a problem when the users switch the application locale to a one that is unsupported by the Oracle JDBC driver (e.g. mk_MK). In this case, the next time I fetch a connection I get the following exception:
ORA-00604: error occurred at recursive SQL level 1
ORA-12705: Cannot access NLS data files or invalid environment specified
I can change the locale on the fly just before I fetch the connection and switch back to the user's selected one back and forth, but this seems unelegant and unefficient.
See also: https://serverfault.com/questions/63216/ora-12705-cannot-access-nls-data-files-or-invalid-environment-specified/64536
For me the best response was by FoxyBOA to invoke java app with:
-Duser.country=en -Duser.language=en
The NLS_LANG settings are derived from the java.util.Locale . Therefore, you will need to make a call similar to this before connecting:
Locale.setDefault(Locale.<your locale here>);
I was fighting the same problem and found out that thin jdbc Oracle drivers do not require NLS_LANG or system locale to be specified. But when you connect to non-english databases you are to have orai18n.jar in the classpath.
from Oracle® Database JDBC Developer’s Guide and Reference
Providing Globalization Support
The basic Java Archive (JAR) files,
ojdbc5.jar and ojdbc6.jar, contain all
the necessary classes to provide
complete globalization support for:
Oracle character sets for CHAR,
VARCHAR, LONGVARCHAR, or CLOB data
that is not being retrieved or
inserted as a data member of an Oracle
object or collection type.
CHAR or
VARCHAR data members of object and
collection for the character sets
US7ASCII, WE8DEC, WE8ISO8859P1,
WE8MSWIN1252, and UTF8.
To use any other character sets in
CHAR or VARCHAR data members of
objects or collections, you must
include orai18n.jar in the CLASSPATH
environment variable of your
application.
Invoking java with the following works for me :
-Duser.country=us -Duser.language=en
if "en" for country also causes ORA-12705.
You should use the old Oracle 9.2 JDBC driver that is fully compatible and certified with Oracle 10g. The old driver does not use ALTER SESSION SET NLS_LANGUAGE commands.