Editing data in grid vs using an update script - sql

I tried using Toad 12.1 DBA and SQLDeveloper to achieve my goal but i got same results.
When i update NVARCHAR2 cell in grid result, i can set and commit '€' sign as value. But when i execute an update script to do the same thing, it prints '?' character as data.
Here is the result when i edit and commit data in grid:
Here is the problem when i use update script to do the same thing:
I tried using differend NLS_LANG parameters but they did not work either.
AMERICAN_AMERICA.WE8ISO8859P9
AMERICAN_AMERICA.AL16UTF16
Database NLS parameters is here:
SELECT * FROM NLS_DATABASE_PARAMETERS where PARAMETER in ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');
PARAMETER VALUE
------------ ------------
NLS_CHARACTERSET WE8ISO8859P9
NLS_NCHAR_CHARACTERSET AL16UTF16
Create script for the simple table:
CREATE TABLE AAA
(
NVARCHAR2COL NVARCHAR2(50)
);
I also tried using sqlplus to execute update script, but it printed question mark as data as well.
Edit: one more thing, using update script with unistr function works but i need to update data by using readable text:
UPDATE AAA SET NVARCHAR2COL = unistr('\20AC');
COMMIT;
Solution: using #Nationalized annotation on my JPA entities for NVARCHAR fields solved my problem.

Default data type of Text Literal is CHAR. CHAR strings can contain only ASCII symbols and there is no '€' symbol in ASCII table, so '€' is converted to '?' during statement compilation.
To use national character set string value must be prefixed with N. N function converts the data at compilation time to NCHAR.
UPDATE AAA SET NVARCHAR2COL = N'€'; should work.
Alternatively UPDATE AAA SET NVARCHAR2COL = to_nchar('€'); can be used.
When updating a value in a grid the development tool does the same transparently for the user.

Related

PostgreSQL database considering the script as ANSI instead of UTF8

I have executed a script that updates a column in a database and that worked well.
The script would be having an update statement as below. It is trying to update the display_name with an inverted comma in it.
Update table1
Set display_name = 'I'm Kumar'
Where internal_name = 'IK';
When I executed the same script in another database, it is updating the display name with some special character in place of an inverted comma. Seems like the script is being considered as Ansi encoded format instead of UTF-8 format.
Please help me to understand why is this happening. Will there be any setting at the database level to change.
Yes, and that setting is client_encoding.
The default value is specified in the server configuration, and the client has to override it if desired:
SET client_encoding = 'UTF8';

Append a column with LONG_RAW datatype - SQL

I am trying to update a column of long raw datatype and later append the value. Is it possible? I have tried || already but not working.
Update acert SET atrt= 'ddddd'
update acert SET atrt = atrt || 'updated value'
Error :
ORA-00932- expected char got binary
I want something like above work.
Also, I cannot use any DDL queries to temporarily alter the table. Is there any other way I could do this?
To manipulate a LONG RAW you pretty much need an external interface (C, Java, etc).
There is not anything natively in SQL or PLSQL that will do it, hence the preference to use CLOB and BLOB.

INSERT Statement in SQL Server Strips Characters, but using nchar(xxx) works - why?

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')

Losing special characters on insert

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

Varchar2 and Oracle quick question

Hi guys I'm using varchar2 for a product name field, but when I query the database from the run SQL command line it shows too many empty spaces, how can I fix this without changing the datatype
here is the link to the ss
http://img203.imageshack.us/img203/20/varchar.jpg
The data that got inserted into the database (probably through some ETL process) had spaces which were not trimmed.
You could update using (pseudo code)
Update Table Set Column = Trim(Column)
If TRIM does not change the results, that tells you that there are not trailing spaces in the actual database rows; they're just being added as part of the formatted screen output.
By default, sqlplus (the command-line Oracle tool you appear to be using) uses the maximum length of the varchar2 column as the (fixed) width when displaying the results of a select statement.
If you want to change this, use the column format sqlplus command before running the select. For example:
column DEPT_NAME format a20
Hi
Try to use trim on both sides,
Update TableName set FieldName = RTrim(LTrim(FieldName))
Regards