How to set DB2 ODBC driver locale? - windows

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

Related

how to make sql developer display diacritic character correctly instead of displaying squares?

I am unable to see the diacritic characters (with accents) in my oracle SQL Developer. I have tried with all the Font option. Is any way I can add the "Arial Unicode MS" font in my oracle SQLDeveloper and see the character instead of the square box.
Since SQL Developer is based on pure Java and JDBC there is the a possibility that the data itself were stored wrong - this could happen when you used not proper client NLS_LANG value and/or wrong codepage (Windows) or LANG (Linux / Unix). Since Data allready in DB and fetch with SQL Developer returns crap, this is by 95% a NLS issue.
Please let us know Database Charachterset and NLS_LANG and Codepage (chcp) settings of client. You can perform
Select <Colname>, dump(<colname>) "Dump" from <table>;
To return a column and dump in Sqlplus.
Provide
NLS_LANG of client
Client codepage (Windows) or LANG (Linux)
Database Charachterset
the value from select,
the expected value and
value from SQL Developer performing the same select as shown above
and we will see 😉

migrating database from access 2003 to oracle Arabic characters are shown as question marks

UPDATE
as answer below shows that is error couse by JDBC so is there any
other suggestion to migrate access database to oracle database other
than using toad and the hard way to do it because trigger views
sequences wont be imported by that way so I have to create them by my
self??! :S
I am migrating database from access 2003 to oracle database 12c but Arabic characters are shown as question marks at the step where you connect to access database using SQL developers
I followed what you suggest at this answer and restart my pc but nothing changed
NOTE
when opening .mdb file from access Arabic characters shown right but when opening it from SQL developers I get question marks instead of arabic characters
is there anything else to do ?
I run that query as #krokodilko suggested and I get below result
select * from nls_database_parameters where parameter like '%CHAR%'
NLS_NCHAR_CONV_EXCP FALSE
NLS_NUMERIC_CHARACTERS .,
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_CHARACTERSET AR8MSWIN1256
select * from nls_session_parameters where parameter like '%LANG%';
NLS_LANGUAGE ENGLISH
NLS_DATE_LANGUAGE ENGLISH
by the way when I open another Oracle schema Arabic characters show correctly dose access has special encoding ?
Unfortunately, this looks like a problem with JDBC-ODBC Bridge. It does not work properly with the Access ODBC driver when text includes Unicode characters.
See other questions regarding MS Access over JDBC-ODBC Bridge like this:
Reading Unicode characters from an Access database via JDBC-ODBC.
There is also proposed solution which may work for general Java-to-MSAccess connection using pure Java JDBC driver (UCanAccess):
Manipulating an Access database from Java without ODBC
But, your question is about using SQL Developer for migration, so, it is not a solution for you, since SQL Developer supports only limited number of JDBC drivers. Not UCanAccess.
Hard-way is better than no-way.

Thai language Configuration in Oracle

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.

SSIS 2008 R2 - Convert Oracle Character set data (with french accent)

I'm trying to extract data out of an Oracle database that is configured with the following:
NLS_CHARACTERSET EE8ISO8859P2
NLS_NCHAR_CHARACTERSET AL16UTF16
I'm working with SSIS 2008 R2 Standard (had to install Oracle 11g Client). Some accent are properly interpreted (e.g: é) but some are received as weird character and I can't find any way to convert them properly :( The Oracle database is used by our ERP that serves many countries around the world which probably explains the character set choice (I'm not debating if it's a good one or not, I'm a SQL Server guy, not Oracle).
I've tried different approach to extract the data from Oracle, none of which succeeded. I thought I could simply use something as:
SELECT CONVERT(FIELDNAME,'UTF8','EE8ISO8859P2') FROM xxx
Without success.. In my ERP I can see the following value:
"modèle" which is read "modcle" with the previous query through SSIS.
I kinda feel that there's no way I'm gonna get the proper data unless there's some magic formula that can be used. Any help would be appreciated.
Thank you.
All you need to do is set your NLS parameters using some ALTER SESSION commands.
Guess the parameter you need to change would be NLS_LANG
See this page for more information:
http://docs.oracle.com/cd/A87860_01/doc/server.817/a76966/ch2.htm
Strangely, I helped one of my teammates today to sort in Swedish using this. Hope it helps you too.

how to use different oracle character sets in one application

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.

Resources