I am using oracle 11g and trying to insert a string containing special UTF8 characters eg '(ε- c'. The NLS character sets for the databse are...
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_CHARACTERSET WE8ISO8859P1
when I copy and paste the above string into a NVARCHAR field it works fine.
if I execute the below I get an upside down question mark in the field
insert into title_debug values ('(ε- c');
where title debug table consists of a single NVARCHAR2(100) field called title.
I have attempted to assign this string to a NVARCHAR2(100) variable then iserting this. And also attempted all the different CAST / CONVERT ect functions I can find and nothing is working.
Any assistance would be greatly appreciated.
UPDATE
I have executed
select dump(title, 1016), dump(title1, 1016)
into v_title, v_title1
from dual
where title is the string passed in as a varchar and title1 is the string passed in as a NVarchar.
Unsuprisingly the encodings come through as WE8ISO8859P1 and AL16UTF16. but on both the ε comes through as hex 'BF'. This is the upside down Question mark.
My only thought left is to try and pass this through as a raw and then do something with it. However I have not yet been able to figure out how to convert the string into a acceptable format with XQuery (OSB).
Continued thanks for assistance.
Our DBA found the solution to this issue. The answer lay in a setting on the dbc connection on the bus to tell it to convert utf8 to NChar.
On The connection pool page add the following lines to the Properties box.
oracle.jdbc.convertNcharLiterals=true
oracle.jdbc.defaultNchar=true
this will allow you to be able to insert into NVarchar2 fields while maintaining the utf8 characters.
Cheers
I did a test with '(ε- c'. And i have not encountered any problems.
If you can i advice you to change your character set for :
NLS_CHARACTERSET AL32UTF8
NLS_NCHAR_CHARACTERSET AL16UTF16
And Oracle recommendation for all new deployment is the Unicode character set AL32UTF8.
Because it's flexible globalization support and is a universal character set
reg,
First verify the data is being stored correctly, then use the correct NLS_LANG settings. See my answer to this question:
when insert persian character in oracle db i see the question mark
Related
I have the following table:
Can i change charset of column SCHEMA_ERD to UTF-8?
If it isn't possible maybe i can change charset only for that table?
Can someone give me example how to do it?
I want to keep emojis inside that SCHEMA_ERD that is why i need change charset to UTF-8.
As far as I can tell, in Oracle, character set is database's characteristic. It means that you should change character set for the whole database (i.e. you can't do that for only one table (or column, or schema).
However, you could use NVARCHAR2 or NCLOB so I suggest you to try it. Because, changing character set is not that simple task.
Issue this query to see your available character sets in your database
select * from nls_database_parameters
where parameter in ( 'NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');
PARAMETER VALUE
------------------------- ----------
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_CHARACTERSET WE8ISO8859P1
The character set in NLS_CHARACTERSET is what is used for normal VARCHAR2.
The NCHAR character set is used for NVARCHAR2 or NCLOB.
You have no other chance wihtout support of your DBA
But note, that the NCHAR character set is typically set to support UTF8 or UTF16 so it should work for you.
I have to store some strange characters in my SQL Server DB which are used by an Epson Receipt Printer code page.
Using an INSERT statement, all are stored correctly except one - [SCI] (nchar(154)). I realise that this is a control character that isn't representable in a string, but the character is replaced by a '?' in the stored DB string, suggesting that it is being parsed (unsuccessfully) somewhere.
The collation of the database is LATIN1_GENERAL_CI_AS so it should be able to cope with it.
So, for example, if I run this INSERT:
INSERT INTO Table(col1) VALUES ('abc[SCI]123')
Where [SCI] is the character, a resulting SELECT query will return 'abc?123'.
However, if I use NCHAR(154), by directly inserting or by using a REPLACE command such as:
UPDATE Table SET col1 = REPLACE(col1, '?', NCHAR(154))
The character is stored correctly.
My question is, why? And how can I store it directly from an INSERT statement? The latter is preferable as I am writing from an existing application that produces the INSERT statement that I don't really want to have to change.
Thank you in advance for any information that may be useful.
When you write a literal string in SQL is is created as a VARCHAR unless you prefix is with N. This means if you include any Unicode characters, they will be removed. Instead write your INSERT statement like this:
INSERT INTO Table(col1) VALUES (N'abc[SCI]123')
I have a problem when inserting values into my Oracle database. I have to insert French characters like à or è and when I try to insert them through an INSERT statement it will convert the character to ¿ or ?.
Is there any possibility to set the encoding of that specific script, or what can I do in this situation ?
Thank you
Usually you would set the character set when you install your database. You can, however, change it post-setup if required (Look up CSALTER). If your database needs to support multiple languages, then you should take a look at this: Supporting Multilingual Databases with Unicode
I have fixed this problem by adding an Environment Variable called NLS_LANG with the value .AL32UTF8 . This worked even though the database has as language American and territory America. The problem that I have faced here was that once I changed the NLS_LANG variable, it started to encode my characters also in the application.
Also you can try to change the encoding of the script that you are running. For example I have used ANSI encoding (you can do it by opening a script in notepad++ and from the Encoding menu, select Convert to ANSI) and it worked properly.
Thank you guys for your help :)
The problem is that DBI's insert leaves long string truncated when inserting to MS SQL server. Here are my codes:
my $insert = $dbh->prepare("INSERT INTO my_table (field_1, field_2) values (?, ?)");
$insert->execute($value_1, $value_2);
where field_2 has data type of varchar(100) and $value_2 is a text string of 90 characters with spaces but no other special characters.
After the statement is executed, with no error raised, I checked the database and apparently the actual inserted $value_2 is truncated at the 80th character, which is in the middle of a regular English word (i.e. not a special character).
I've tried to alter the data type of field_2 to varchar(150) and text. I've also used $dbh->quote($value_2) in place of $value_2. But they didn't help.
Why is this happening? What should I do? Thx!!
If you are using freeTDS it is probably a bug identified in the freeTDS mailing list. See freetds silently truncating text/varchar/etc fields to 80 characters and http://lists.ibiblio.org/pipermail/freetds/2011q2/026943.html and http://lists.ibiblio.org/pipermail/freetds/2011q2/026925.html and http://lists.ibiblio.org/pipermail/freetds/2011q2/026944.html
I'd say try various strings to see if they all behave the same way. It's probably an encoding issue as davorg suggests. The default collation in MySQL is Swedish or Latin1 as I recall, so in MySQL you'll probably want to change your collation to utf8_general_ci.
When I update my database with this command:
UPDATE myTable SET Name = 'Hermann Dönnhoff' WHERE ID = 123;
SQL Server actually puts 'Hermann Do¨nnhoff' in the field instead. Instead of faithfully inserting the o-umlaut (char(246)), I'm getting two characters ( char(111) + char (168) ).
This happens for all characters that have accent marks, not just umlauts.
Has anybody seen this?
Thank you.
You need to use the nchar, nvarchar, or ntext datatypes for Unicode data.
The issue is that your code page does not directly support those characters.
Read up on collations for more information:
http://msdn.microsoft.com/en-us/library/aa214408%28SQL.80%29.aspx
http://msdn.microsoft.com/en-us/library/aa174903%28SQL.80%29.aspx