I have Oracle database with following settings
NLS_CHARACTERSET EE8MSWIN1250
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_LANGUAGE AMERICAN
I've created test table with one column of type NVARCHAR2, where I'm going to store cyrillic.
I use SQL Developer to connect DB.
The problem is when I put a cyrillic chain into DB using SQL Developer cell, the data is stored correctly. But when I use INSERT query with the same data using N'' or not the data is stored as question marks.
Interesting thing is that query generated by SQL Developer, and written by me is identical.
I solved this problem by changing NLS_CHARACTERSET to UTF8, but on production server I can't do such a thing.
IMO it must be some way to store cyrillic into that DB in proper way using query if SQL Developer can do that.
Regards
Depending on the ODBC/JDBC in use, localization settings on your computer may override any config values in the database. Try using ALTER SESSION and set the proper NLS parameters before executing your query, and see if that helps. SQL developer might do this behind the scenes when you edit the data cell.
Related
The current encoding of oracle instance is WE8ISO8859P1 and needs to be moved to UTF-8. I have found some challenges in my database instance due to its current setup and requirements of my business.
This instance in question has 100+ schema users with number of tables created under each schema. We can say logically each schema exists for application or specific system within the enterprise. The requirement is to move only certain schema and their table objects to new character set of UTF-8.
Also, remember the reason for this migration right now is compliance with Restful POST calls that will perform CRUD operations in UTF format.
NLS_NCHAR_CHARACTERSET- AL16UTF16
NLS_CHARACTERSET- WE8ISO8859P1
I did do some research earlier and here are my findings.
• Oracle doesn’t support character encoding at the tablespace , table or column level. Therefore options start reducing for any charset migration strategy at schema level only.
• We have CRUD calls by other enterprise legacy systems to this schema. Therefore should not have a any wider impact. Off course, other schema's in this instance doesn't have any requirements of UTF-8.
The only way I see a solution is
OPTION 1 - Move the target schema and thier objects into new database instance with NLS_LANGUAGE to be UTF-8.
OPTION 2 - Converting all the relevant columns to NCHAR and NVARCHAR but with loss of length and truncation.
Both the approaches lead to big impact and not able to conclude what is best. Any suggestions are welcome that solves my charset migration without impact and changes to other schema in the instance.
We are using Oracle and we have a requirement to allow greek characters to be stored in the DB. Currently, our DB instance doesn't let us insert greek characters such as 'ϕ'. On googling, I found that it is to do with the character set. My oracle uses NLS_CHARACTERSET - WE8MSWIN1252 that doesn't support greek characters. I will have to change the character set to one of AL32UTF8, UTF8, AL16UTF16 or WE8ISO8859P7 if it has to work. Now that we have so much of data in the DB already, it would be a risk to change the character set now.
The other option I have is to change the column type (used to insert greek) from CLOB or VARCHAR2 to NVARCHAR2 and it works fine.
Before changing the column type, I want to know what are the risks involved in changing column type from CLOB to NVARCHAR2 and what are the things I need to keep in mind before changing.
Also, I would like to know the pros and cons of changing my existing character set to AL32UTF8.
EDIT:
There is also an option of changing CLOB to NCLOB and this seems to be less risky as both are closely related (almost same) types. Please do let me know the pros and cons of changing CLOB to NCLOB.
Ok. I was googling and posting Qs in other forums and got a much needed answer in here.
https://www.toolbox.com/tech/oracle/question/migrating-clob-to-nclob-010917/
So I just encountered this myself and I had issues with the above solution as it didn't copy across the foreign keys and constraints of my other columns. To get round this I did the following
created a new column for my NCLOB data,
ALTER TABLE table_name
ADD new_table_column NCLOB;
I then copied my CLOB data into my new NCLOB data column using the TO_NCLOB() function
UPDATE table_name
SET new_table_column = TO_NCLOB(old_table_column);
3)Finally I dropped the old column and then renamed my new column to my old column name
ALTER TABLE table_name
DROP COLUMN old_table_column;
ALTER TABLE table_name
RENAME COLUMN new_table_column TO old_table_column;
Please make sure you backup your data if you do this though as dropping the column will get rid of it and commit any transactions you've got
I also did this in Oracle so the syntax may differ slightly in other versions of SQL.
I am having issues with a numeric format on my db.
I checked the NSL_Parameters and there is a difference between the database ones and session ones.
Can someone explain me if on this case, the queries will have the session format or the database one?
Your queries will always use the session NLS_Parameters. Actually most of all NLS_Parameters on database are only used to define the default session parameters if they are not set.
I think NLS_CHARACTERSET is the only NLS_Parameter which is relevant only on database level and cannot be changed on session level.
I am getting the following error:
Microsoft OLE DB Provider for Oracle: Data type is not supported.
Could somebody help me figure out this please...
Situation:
Recently migrated database from SQL Server 2005 to Oracle 11g. One of the table has some columns of the data type ntext in SQL Server, which were converted to NCLOB during migration to Oracle. Client is Classic ASP page (VBScript) accessing the Oracle Database through OLEDB connection.
When the execution reaches the query (Select query) that reads the column of type NCLOB it is throwing the Microsoft OLE DB Provider for Oracle: Data type is not supported error. When I take out that particular column then the query is running fine...
QUESTION: How to read NCLOB, CLOB data values from Classic ASP pages?
Plz let me know if you need more information.....
Thank You..
I know that Microsoft's ODBC Driver for Oracle didn't support any of the LOB types-- I would wager that its OLE DB Provider didn't either given the error. Can you upgrade to the Oracle OLE DB Provider?
As an aside, since you are migrating from SQL Server to Oracle, do you really need to use the NCLOB data type? Since Oracle allows the database character set to be Unicode, you normally don't need (and don't want) to use the NVARCHAR2 or NCLOB data types unless you're stuck supporting an old database that requires a non-Unicode character set. For data that is English or Western Eurpoean in nature, storing data in a CLOB has substantial benefits in terms of storage space since the CLOB would store the data in UTF-8 rather than UTF-16 in an NCLOB (assuming that you picked a Unicode character set for the database). Eliminating the NVARCHAR2 and NCLOB columns also tends to make it much easier for front-end tools to handle the data.
I'm trying to figure out where our project went wrong.
A long time ago, our database administrator created a user and a schema for the project we were working on.
We gave that user to a contractor who created the tables and installed the application.
Today I discovered that our database doesn't support UTF-8 characters and we need it to.
select value from nls_database_parameters
where parameter='NLS_CHARACTERSET'
The result is : WE8ISO8859P1
My question is, was the mistake made when the user was created, or was the mistake done by the contractor who created the tables?
Thanks
The character set is an attribute of the database. So whoever created the database presumably chose the wrong character set. There are no character set related settings when you create a user or create a table (other than determining whether to use the database character set (CHAR/ VARCHAR2) or the national character set (NCHAR/ NVARCHAR2) data types).
Changing the character set of an existing database may take a bit of effort. The Globalization Guide has a section on character set migration. Depending on the Oracle version (the procedure is different in 10g and 11g) and what data already exists, doing an export & import to a new database may be the easiest option.
I should add that the order of operations you specified in your post doesn't make sense. The database has to be created before the user or the schema can be created. So it doesn't make sense that the DBA could have created the user and the schema a long time ago and the contractor created the database more recently. Are you possibly using the terms "database" and "schema" in a non-Oracle context?