i'm developing a 32bit Client-Application with Delphi. From this application I need to connect to databases on two different servers. First databse character set ist WE8MSWIN1252, the other server decodes with WE8PC850. Setting the client NLS_LANG parameter to the correct value solves correct sql-query results.
Unfortunately this (the client character-set) seems only to be recognized on applications startup (first connect to oracle). I need to change the client-characterset at runtime. Oracle client seems to store the character set an application used to connect!
beside: I#m using udl-files to setup the connections (Microsoft OLE DB - driver)
what can I do?
You could use ALTER SESSION calls to change the settings at the session level after connecting to the database.
I need to change the
client-characterset at runtime.
Why ? I would have thought what you want at the client end is a character set that is acceptable to the operating environment and end-user.
Pick out a character set such as UTF-8 and let Oracle handle the conversion between the client character set and the two database character sets.
Related
We have Oracle 11g database with EE8ISO8859P2 character set. This character set can’t be changed, i.e. it must stay as it is.
However the data that will be inserted and read from the database will be from another character set: CL8MSWIN1251.
We are using .NET and ODP. One possible approach is manual transliteration in the .NET application itself.
Is the following scenario with Oracle 11g, .NET and ODP feasible?
Data is stored on the server into database with EE8ISO8859P2 character set encoding.
ADO.NET ODP driver connects to the database and retrieves the character data as opaque bytes which are further decoded in the .NET client by using the mapping: CL8MSWIN1251=>CLR Unicode.
We have tried with NLS_LANG environment variable but that did not solve the problem.
Any suggestions?
I assume you mean ODP instead of ODC.
I don't think your proposal is a good idea. Of course, it is always possible to "cheat" the database character inside your .NET application. But imagine a DBA has to analyze an issue on the database. Usually he will use a tool like SQL*Plus, SQL Developer, or similar. Or what happens when another tool access the database, e.g. for reporting purpose. All these topics will not work.
An Oracle database actually has two character sets, the "normal" one the the "national" one. Perhaps you can use the second characters set by using NVARCHAR or NCHAR datatypes.
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.
We have a BPEL process that is taking characters (e.g. Chinese) and attempts to insert them into an NVARCHAR column. The XML payload looks correct throughout the various stages (and we see the encoding is UTF-8) but when it comes to the actual INSERT we are seeing incorrect characters. Our theory is that the DB Adapter could be the problem but we do not know for sure.
Is there a way to examine the version and config of the DB Adapter, to see if it can handle UTF-8 and Unicode? We have successfully inserted Chinese and Hewbrew characters into the database using TOAD, Java servlets, etc. so the database itself is configured. It is Oracle version 9.2.0.8.0.
It may be that the fault is elsewhere than the DB Adapter so we are trying to eliminate things. Would it be worth trying to look at the HTTP header to check the encoding here?
Thanks
We got to the bottom of this in the end. In a WSDL file (as part of the database connection details) we specified the defaultNChar=true property as an attribute and this was passed on to the database driver.
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.