Specifying character set on application import

hi --
I'm running into a problem that I think has to do w/ character sets.
I'm using non-breaking spaces in numerous LOVs; they're entered in as ALT +0160 on the keypad. These non-breaking spaces work great in the development environment of APEX (eg in the development app), and now I need to export/import the app to a production environment, which is runtime only.
The NLS_CHARACTERSET on both the development and production databases is US7ASCII.
When I import the app into the runtime installation of APEX I simply run the export file in sqlplus as the schema user.
(It has been scp'd over, as a text file, from the development server.)
The application imports and runs fine, but the non breaking spaces are displayed as garbage characters.
I did some testing on apex.oracle.com. I noticed that when I specify character set of unicode utf-8 on import,
the non-breaking spaces work properly. When I specify US-ASCII, I get the same garbage I'm getting in
my production environment.
When I export the app from the development environment, the character set is fixed (cannot be changed) to unicode utf-8. But I'm not doing anything to set the character set on import (don't know that I can...), and I wonder if it's adopting the database default character set of ASCII.
How can I get the imported app to use the desired character set? Am I going to have to convert this to a development
environment just so I can specify the character set on import, or is there a way to do it in sqlplus?
I'm not entirely sure I'm on the right track... but maybe someone has ideas how to get these non breaking spaces working in the production environment.
If access to my workspace on apex.oracle.com would be helpful, let me know.
Thanks,
Carol

I forgot to mention that, from what I've recently read, ASCII does not have a representation for non breaking spaces... so the behavior I'm experiencing is at least consistent with that...

Similar Messages

Character set mismatch during import

I have exported a tablespace from a database using transportable tablespace option
with CHARACTERSET UTF8. And I tried to import into another db where the CHARACTERSET is US7ASCII. Now it says that it cannot import because the charactersets are different. Is there any way to get around this problem?
Regards,
Kallur Manoj.

Manoj,
One of the limitations for transportable tablespace is that the source and target databases should use the same character set and national character set.
You may need to either export the tablespace with us7ascii, or import to a db with utf8 characterset.
AGK

How do I specify character set encoding?

Hi,
I already defined sub-class META from DOCUMENT class thru xml.
Now I am trying to upload META files thru xml and its working fine.
But when I see properties from web, I don't see "Character Set" define.
As a result I can't use BufferedReader(doc.getContentReader())
Exception in thread "main" oracle.ifs.common.IfsException: IFS-32245: Cannot con
vert content to Reader - content does not have an associated character encoding.
at oracle.ifs.server.S_Media.convertInputStreamToReader(S_Media.java:1960)
at oracle.ifs.server.S_Media.getReaderFromObject(S_Media.java:1423)
at oracle.ifs.server.S_Media.getContentReader(S_Media.java:1408)
How can I specify encoding character set from xml?
Of if possible can I specify while defining class(META in this case).
Thanks,
-Niraj

Luis,
Each take encoding name arguments using the Java naming conventions.
If you want to do this automatically when you upload your XML file, you
will need to write a server-side representation of your "META" ClassObject
and provide an 'extendedPostInsert' implementation. In this method, you can
parse the XML content and pull out an encoding if you specify it within the
XML file. Could you explain in little more details?
If you can provide me links to any resouces, that would be great.
Thanks,
-Niraj

Character set issue after import?

Hi,
Source DB version:10.2.0.1
OS:Red hat Linux
Target DB version:10.2.0.1
OS:Windows server
source database character set:AL32UTF8
Performed the export as below
$export NLS_LANG=AMERICAN.AL32UTF8
Performed the full database export and it finished successfully with out any warnings
Export done in AL32UTF8 character set and AL16UTF16 NCHAR character set
Now imported into the target database as below.
target database character set:AL32UTF8
c:\>set NLS_LANG=AMERICAN.AL32UTF8
now run import command which imported successfully with out any warnings.
However I’m having problems with Greek characters. Most of them are shown as ?, while some of them are converted to Latin chars
For example:
This was supposed to be Αγγελική ???e????
And this Κουκουτσάκη ??????ts???
While this one should be Δήμητρα ??µ?t?a
From the import log file I can see that ‘import done in AL32UTF8 character set and AL16UTF16 NCHAR character set’ which I believe is correct.
Can any one tell me how i can over come this problem of greek charecters.
Thank you all.

PARAMETER
VALUE
NLS_LANGUAGE
AMERICAN
NLS_TERRITORY
AMERICA
NLS_CURRENCY
$
PARAMETER
VALUE
NLS_ISO_CURRENCY
AMERICA
NLS_NUMERIC_CHARACTERS
NLS_CHARACTERSET
AL32UTF8
PARAMETER
VALUE
NLS_CALENDAR
GREGORIAN
NLS_DATE_FORMAT
DD-MON-RR
NLS_DATE_LANGUAGE
AMERICAN
PARAMETER
VALUE
NLS_SORT
BINARY
NLS_TIME_FORMAT
HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT
DD-MON-RR HH.MI.SSXFF AM
PARAMETER
VALUE
NLS_TIME_TZ_FORMAT
HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT
DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY
$
PARAMETER
VALUE
NLS_COMP
BINARY
NLS_LENGTH_SEMANTICS
BYTE
NLS_NCHAR_CONV_EXCP
FALSE
PARAMETER
VALUE
NLS_NCHAR_CHARACTERSET
AL16UTF16
NLS_RDBMS_VERSION
10.2.0.1.0
20 rows selected.

Character set in MDL export/import

Hi,
we are running OWB 10.1.0.2. In order to get version control, we perform MDL exports of collections from our development environment and then import them into our test and production environments. Each environment uses its own design repository, but all repositories are in the same database.
When doing an export of a collection, we always specify the character set AL32UTF8 because that is what we are running in the repository database. When later doing an import using the graphical user interface, it is not possible to specify the character set (but this can be done when using the import utility). According to the documentation, the GUI import will then assume that the character set in the collection is the character set of the client, which usually is WE8MSWIN1252. (The documentation also says that it IS possible to specify the character set during GUI import, this is obviously a documentation error).
My questions are: What is the point of specifying character set when doing exports and imports? Could an AL32UTF8 export followed by an WE8MSWIN1252 import cause problems? I assume that the character set used by export is specified in the collection file, so does the import then convert it to WE8MSWIN1252 (or the character set specified in the import utility)?
Or, to be more general: What is actually happening with the character sets during MDL export/import?
/Kjell Gullberg

Dear ski123,
I think you are not going to loose any data of yours when you migrate the database. You may proceed to the import.
Please find below documentations;
http://download.oracle.com/docs/cd/B19306_01/server.102/b14196/install003.htm#sthref81
For Database Character Set, select from one of the following options:
    *Use the Default—Select this option if you need to support only the language currently used by the operating system for all your database users and your database applications.
    *Use Unicode (AL32UTF8)—Select this option if you need to support multiple languages for your database users and your database applications.
    *Choose from the list of character sets—Select this option if you want the Oracle Database to use a character set other than the default character set used by the operating system.Choosing a Character Set;
http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/ch2charset.htm#NLSPG002
AL32UTF8;
http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/glossary.htm#sthref2039
Hope That Helps.
Ogan

Character set marker unknown error while importing data in 10g from 8i

Hi All,
I am trying to import the whole database schema wise (one by one) through oracle 10g database control page (which is browser based)
But when i try to import the objects of a schema i get the error that
"IMP-00037 : Character set marker unknown "
Import terminated unsuccessfully
Would anybody please tell me about the mentioned error ???
Kindly provide the solution.
Mentioned below are the character sets available in both the version.
Character sets in oracle 8.1.7 :-
Database Character Set :: WE8ISO8859P1
National Character Set :: WE8ISO8859P1
Character sets in oracle 10.2.0.1.0 :-
Database Character Set :: WE8ISO8859P1
National Character Set :: AL16UTF16
Regards
Milin...
Message was edited by:
user640001

Hi,
As you have asked, i have mentioned the export command below to get the full database export file.
And I have copied this export file (dump) to another machine(Server) where i have to import that file to upgrade the database to 10g Rel 2.
SET CC=%DATE:~4,2%-%DATE:~7,2%-%DATE:~10,4%
exp username/password@db_name
file=D:\PAY_BKP\EXP_FULL_PAY_%CC%.DMP log=D:\PAY_BKP\EXP_FULL_PAY.log
indexes=yes
full=yes
Kindly provide guidance.
Regards
Milin

Import error due to character set difference?

hi,
hoping anyone to explain reason for the following import error.
here's the situation,
- export client used WE8MSWIN1252 charset (release v10.02.01)
- import server used WE8ISO8859P1 charset (release v10.1.0.4)
all tables appeared to be imported without error, except that import terminated unsuccesfully due to oracle error 2248
"ALTER SESSION SET PLSQL_OPTIMIZE_LEVEL =1 NLS-LENGTH_SEMANTICS = 'BYTE' PLSQL_CODE_TYPE = 'INTERPRETED' PLSQL_DEBUG = FALSE PLSQL_WARNING = 'DISABLE:ALL' PLSQL_CCFLAGS =''"
ORA-02248: invalid option for ALTER SESSION
was error due to the difference release version? char set conversion to non superset?
appreciate any help pls

It is difficult to say what is the current state of the database, so it is recommended to reexport and reimport the object definitions. You may miss some other stuff like object types, contraints, etc. Table data should be OK, so reexport should not include data.
As far as character sets are concerned, because of the difference between the export client character set and the import server character set, you may have lost some characters in the code range 0x80-0x9f. This includes Euro sign, TM, sign, "smart" quotes, en- and em-dash, etc. Use the Windows charmap.exe to see all the codes. If you have some of these codes in the source database, you have lost them on import (they got converted to the reverse quotation mark code 0xbf).
-- Sergiusz

Change character set

Hi
is anyone can tell me how to change characterset.
i try with alter session but it doesnt work.
thanks

Article from Metalink
Doc ID:      Note:66320.1
Subject:      Changing the Database Character Set or the Database National Character Set
Type:      BULLETIN
Status:      PUBLISHED
     Content Type:      TEXT/PLAIN
Creation Date:      23-OCT-1998
Last Revision Date:      12-DEC-2003
PURPOSE ======= To explain how to change the database character set or national character set of an existing Oracle8(i) or Oracle9i database without having to recreate the database. 1. SCOPE & APPLICATION ====================== The method described here is documented in the Oracle 8.1.x and Oracle9i documentation. It is not documented but it can be used in version 8.0.x. It does not work in Oracle7. The database character set is the character set of CHAR, VARCHAR2, LONG, and CLOB data stored in the database columns, and of SQL and PL/SQL text stored in the Data Dictionary. The national character set is the character set of NCHAR, NVARCHAR2, and NCLOB data. In certain database configurations the CLOB and NCLOB data are stored in the fixed-width Unicode encoding UCS-2. If you are using CLOB or NCLOB please make sure you read section "4. HANDLING CLOB AND NCLOB COLUMNS" below in this document. Before changing the character set of a database make sure you understand how Oracle deals with character sets. Before proceeding please refer to [NOTE:158577.1] "NLS_LANG Explained (How Does Client-Server Character Conversion Work?)". See also [NOTE:225912.1] "Changing the Database Character Set - an Overview" for general discussion about various methods of migration to a different database character set. If you are migrating an Oracle Applications instance, read [NOTE:124721.1] "Migrating an Applications Installation to a New Character Set" for specific steps that have to be performed. If you are migrating from 8.x to 9.x please have a look at [NOTE:140014.1] "ALERT: Oracle8/8i to Oracle9i Using New "AL16UTF16"" and other referenced notes below. Before using the method described in this note it is essential to do a full backup of the database and to use the Character Set Scanner utility to check your data. See the section "2. USING THE CHARACTER SET SCANNER" below. Note that changing the database or the national character set as described in this document does not change the actual character codes, it only changes the character set declaration. If you want to convert the contents of the database (character codes) from one character set to another you must use the Oracle Export and Import utilities. This is needed, for example, if the source character set is not a binary subset of the target character set, i.e. if a character exists in the source and in the target character set but not with the same binary code. All binary subset-superset relationships between characters sets recognized by the Oracle Server are listed in [NOTE:119164.1] "Changing Database Character Set - Valid Superset Definitions". Note: The varying width character sets (like UTF8) are not supported as national character sets in Oracle8(i) (see [NOTE:62107.1]). Thus, changing the national character set from a fixed width character set to a varying width character set is not supported in Oracle8(i). NCHAR types in Oracle8 and Oracle8i were designed to support special Oracle specific fixed-width Asian character sets, that were introduced to provide higher performance processing of Asian character data. Examples of these character sets are : JA16EUCFIXED ,JA16SJISFIXED , ZHT32EUCFIXED. For a definition of varying width character sets see also section "4. HANDLING CLOB AND NCLOB COLUMNS" below. WARNING: Do not use any undocumented Oracle7 method to change the database character set of an Oracle8(i) or Oracle9i database. This will corrupt the database. 2. USING THE CHARACTER SET SCANNER ================================== Character data in the Oracle 8.1.6 and later database versions can be efficiently checked for possible character set migration problems with help of the Character Set Scanner utility. This utility is included in the Oracle Server 8.1.7 software distribution and the newest Character Set Scanner version can be downloaded from the Oracle Technology Network site, http://otn.oracle.com The Character Set Scanner on OTN is available for limited number of platforms only but it can be used with databases on other platforms in the client/server configuration -- as long as the database version matches the Character Set Scanner version and platforms are either both ASCII-based or both EBCDIC-based. It is recommended to use the newest Character Set Scanner version available from the OTN site. The Character Set Scanner is documented in the following manuals: - "Oracle8i Documentation Addendum, Release 3 (8.1.7)", Chapter 3 - "Oracle9i Globalization Support Guide, Release 1 (9.0.1)", Chapter 10 - "Oracle9i Database Globalization Support Guide, Release 2 (9.2)", Chapter 11 Note: The Character Set Scanner coming with Oracle 8.1.7 and Oracle 9.0.1 does not have a separate version number. It reports the database release number in its banner. This version of the Scanner does not check for illegal character codes in a database if the FROMCHAR and TOCHAR (or FROMNCHAR and TONCHAR) parameters have the same value (i.e. you simulate migration from a character set to itself). The Character Set Scanner 1.0, available on OTN, reports its version number as x.x.x.1.0, where x.x.x is the database version number. This version adds a few bug fixes and it supports FROMCHAR=TOCHAR provided it is not UTF8. The Character Set Scanner 1.1, available on OTN and with Release 2 (9.2) of the Oracle Server, reports its version number as v1.1 followed by the database version number. This version adds another bug fixes and the full support for FROMCHAR=TOCHAR. None of the above versions of the Scanner can correctly analyze CLOB or NCLOB values if the database or the national character set, respectively, is multibyte. The Scanner reports such values randomly as Convertible or Lossy. The version 1.2 of the Scanner will mark all such values as Changeless (as they are always stored in the Unicode UCS-2 encoding and thus they do not change when the database or national character set is changed from one multibyte to another). Character Set Scanner 2.0 will correctly check CLOBs and NCLOBs for possible data loss when migrating from a multibyte character set to its subset. To verify that your database contains only valid codes, specify the new database character set in the TOCHAR parameter and/or the new national character set in the TONCHAR parameter. Specify FULL=Y to scan the whole database. Set ARRAY and PROCESS parameters depending on your system's resources to speed up the scanning. FROMCHAR and FROMNCHAR will default to the original database and national character sets. The Character Set Scanner should report only Changless data in both the Data Dictionary and in application data. If any Convertible or Exceptional data are reported, the ALTER DATABASE [NATIONAL] CHARACTER SET statement must not be used without further investigation of the source and type of these data. In situations in which the ALTER DATABASE [NATIONAL] CHARACTER SET statement is used to repair an incorrect database character set declaration rather than to simply migrate to a new wider character set, you may be advised by Oracle Support Services analysts to execute the statement even if Exceptional data are reported. For more information see also [NOTE:225912.1] "Changing the Database Character Set - a short Overview". 3. CHANGING THE DATABASE OR THE NATIONAL CHARACTER SET ====================================================== Oracle8(i) introduces a new documented method of changing the database and national character sets. The method uses two SQL statements, which are described in the Oracle8i National Language Support Guide: ALTER DATABASE [<db_name>] CHARACTER SET <new_character_set> ALTER DATABASE [<db_name>] NATIONAL CHARACTER SET <new_NCHAR_character_set> The database name is optional. The character set name should be specified without quotes, for example: ALTER DATABASE CHARACTER SET WE8ISO8859P1 To change the database character set perform the following steps. Note that some of them have been erroneously omitted from the Oracle8i documentation: 1. Use the Character Set Scanner utility to verify that your database contains only valid character codes -- see "2. USING THE CHARACTER SET SCANNER" above. 2. If necessary, prepare CLOB columns for the character set change -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below. Omitting this step can lead to corrupted CLOB/NCLOB values in the database. If SYS.METASTYLESHEET (STYLESHEET) is populated (9i and up only) then see [NOTE:213015.1] "SYS.METASTYLESHEET marked as having convertible data (ORA-12716 when trying to convert character set)" for the actions that need to be taken. 3. Make sure the parallel_server parameter in INIT.ORA is set to false or it is not set at all. 4. Execute the following commands in Server Manager (Oracle8) or sqlplus (Oracle9), connected as INTERNAL or "/ AS SYSDBA": SHUTDOWN IMMEDIATE; -- or NORMAL <do a full database backup> STARTUP MOUNT; ALTER SYSTEM ENABLE RESTRICTED SESSION; ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0; ALTER SYSTEM SET AQ_TM_PROCESSES=0; ALTER DATABASE OPEN; ALTER DATABASE CHARACTER SET <new_character_set>; SHUTDOWN IMMEDIATE; -- OR NORMAL STARTUP RESTRICT; 5. Restore the parallel_server parameter in INIT.ORA, if necessary. 6. Execute the following commands: SHUTDOWN IMMEDIATE; -- OR NORMAL STARTUP; The double restart is necessary in Oracle8(i) because of a SGA initialization bug, fixed in Oracle9i. 7. If necessary, restore CLOB columns -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below. To change the national character set replace the ALTER DATABASE CHARACTER SET statement with ALTER DATABASE NATIONAL CHARACTER SET. You can issue both statements together if you wish. Error Conditions ---------------- A number of error conditions may be reported when trying to change the database or national character set. In Oracle8(i) the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return: ORA-01679: database must be mounted EXCLUSIVE and not open to activate - if you do not enable restricted session - if you startup the instance in PARALLEL/SHARED mode - if you do not set the number of queue processes to 0 - if you do not set the number of AQ time manager processes to 0 - if anybody is logged in apart from you. This error message is misleading. The command requires the database to be open but only one session, the one executing the command, is allowed. For the above error conditions Oracle9i will report one of the errors: ORA-12719: operation requires database is in RESTRICTED mode ORA-12720: operation requires database is in EXCLUSIVE mode ORA-12721: operation cannot execute when other sessions are active Oracle9i can also report: ORA-12718: operation requires connection as SYS if you are not connect as SYS (INTERNAL, "/ AS SYSDBA"). If the specified new character set name is not recognized, Oracle will report one of the errors: ORA-24329: invalid character set identifier ORA-12714: invalid national character set specified ORA-12715: invalid character set specified The ALTER DATABASE [NATIONAL] CHARACTER SET command will only work if the old character set is considered a binary subset of the new character set. Oracle Server 8.0.3 to 8.1.5 recognizes US7ASCII as the binary subset of all ASCII-based character sets. It also treats each character set as a binary subset of itself. No other combinations are recognized. Newer Oracle Server versions recognize additional subset/superset combinations, which are listed in [NOTE:119164.1]. If the old character set is not recognized as a binary subset of the new character set, the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return: - in Oracle 8.1.5 and above: ORA-12712: new character set must be a superset of old character set - in Oracle 8.0.5 and 8.0.6: ORA-12710: new character set must be a superset of old character set - in Oracle 8.0.3 and 8.0.4: ORA-24329: invalid character set identifier You will also get these errors if you try to change the characterset of a US7ASCII database that was started without a (correct) ORA_NLSxx parameter. See [NOTE:77442.1] It may be necessary to switch off the superset check to allow changes between formally incompatible character sets to solve certain character set problems or to speed up migration of huge databases. Oracle Support Services may pass the necessary information to customers after verifying the safety of the change for the customers' environments. If in Oracle9i an ALTER DATABASE NATIONAL CHARACTER SET is issued and there are N-type colums who contain data then this error is returned: ORA-12717:Cannot ALTER DATABASE NATIONAL CHARACTER SET when NCLOB data exists The error only speaks about Nclob but Nchar and Nvarchar2 are also checked see [NOTE:2310895.9] for bug [BUG:2310895] 4. HANDLING CLOB AND NCLOB COLUMNS ================================== Background ---------- In a fixed width character set codes of all characters have the same number of bytes. Fixed width character sets are: all single-byte character sets and those multibyte character sets which have names ending with 'FIXED'. In Oracle9i the character set AL16UTF16 is also fixed width. In a varying width character set codes of different characters may have different number of bytes. All multibyte character sets except those with names ending with FIXED (and except Oracle9i AL16UTF16 character set) are varying width. Single-byte character sets are character sets with names of the form xxx7yyyyyy and xxx8yyyyyy. Each character code of a single-byte character set occupies exactly one byte. Multibyte character sets are all other character sets (including UTF8). Some -- usually most -- character codes of a multibyte character set occupy more than one byte. CLOB values in a database whose database character set is fixed width are stored in this character set. CLOB values in an Oracle 8.0.x database whose database character set is varying width are not allowed. They have to be NULL. CLOB values in an Oracle >= 8.1.5 database whose database character set is varying width are stored in the fixed width Unicode UCS-2 encoding. The same holds for NCLOB values and the national character set. The UCS-2 storage format of character LOB values, as implemented in Oracle8i, ensures that calculation of character positions in LOB values is fast. Finding the byte offset of a character stored in a varying width character set would require reading the whole LOB value up to this character (possibly 4GB). In the fixed width character sets the byte offsets are simply character offsets multiplied by the number of bytes in a character code. In UCS-2 byte offsets are simply twice the character offsets. As the Unicode character set contains all characters defined in any other Oracle character set, there is no data loss when a CLOB/NCLOB value is converted to UCS-2 from the character set in which it was provided by a client program (usually the NLS_LANG character set). CLOB Values and the Database Character Set Change ------------------------------------------------- In Oracle 8.0.x CLOB values are invalid in varying width character sets. Thus you must delete all CLOB column values before changing the database character set to a varying width character set. In Oracle 8.1.5 and later CLOB values are valid in varying width character sets but they are converted to Unicode UCS-2 before being stored. But UCS-2 encoding is not a binary superset of any other Oracle character set. Even codes of the basic ASCII characters are different, e.g. single-byte code for "A"=0x41 becomes two-byte code 0x0041. This implies that even if the new varying width character set is a binary superset of the old fixed width character set and thus VARCHAR2/LONG character codes remain valid, the fixed width character codes in CLOB values will not longer be valid in UCS-2. As mentioned above, the ALTER DATABASE [NATIONAL] CHARACTER SET statement does not change character codes. Thus, before changing a fixed width database character set to a varying width character set (like UTF8) in Oracle 8.1.5 or later, you first have to export all tables containing non-NULL CLOB columns, then truncate these tables, then change the database character set and, finally, import the tables back to the database. The import step will perform the required conversion. If you omit the steps above, the character set change will succeed in Oracle8(i) (Oracle9i disallows the change in such situation) and the CLOBs may appear to be correctly legible but as their encoding is incorrect, they will cause problems in further operations. For example, CREATE TABLE AS SELECT will not correctly copy such CLOB columns. Also, after installation of the 8.1.7.3 server patchset the CLOB columns will not longer be legible. LONG columns are always stored in the database character set and thus they behave like CHAR/VARCHAR2 in respect to the character set change. BLOBs and BFILEs are binary raw datatypes and their processing does not depend on any Oracle character set setting. NCLOB Values and the National Character Set Change -------------------------------------------------- The above discussion about changing the database character set and exporting and importing CLOB values is theoretically applicable to the change of the national character set and to NCLOB values. But as varying width character sets are not supported as national character sets in Oracle8(i), changing the national character set from a fixed width character set to a varying width character set is not supported at all. Preparing CLOB Columns for the Character Set Change --------------------------------------------------- Take a backup of the database. If using Advanced Replication or deferred transactions functionality, make sure that there are no outstanding deferred transactions with CLOB parameters, i.e. DEFLOB view must have no rows with non-NULL CLOB_COL column; to make sure that replication environment remains consistent use only recommended methods of purging deferred transaction queue, preferably quiescing the replication environment. Then: - If changing the database character set from a fixed width character set to a varying with character set in Oracle 8.0.x, set all CLOB column values to NULL -- you are not allowed to use CLOB columns after the character set change. - If changing the database character set from a fixed width character set to a varying width character set in Oracle 8.1.5 or later, perform table-level export of all tables containing CLOB columns, including SYSTEM's tables. Set NLS_LANG to the old database character set for the Export utility. Then truncate these tables. Restoring CLOB Columns after the Character Set Change ----------------------------------------------------- In Oracle 8.1.5 or later, after changing the character set as described above (steps 3. to 6.), restore CLOB columns exported in step 2. by importing them back into the database. Set NLS_LANG to the old database character set for the Import utility to avoid IMP-16 errors and data loss. RELATED DOCUMENTS: ================== [NOTE:13856.1] V7: Changing the Database Character Set -- This note has limited distribution, please contact Oracle Support [NOTE:62107.1] The National Character Set in Oracle8 [NOTE:119164.1] Changing Database Character set - Valid Superset definitions [NOTE:118242.1] ALERT: Changing the Database or National Character Set Can Corrupt LOB Values <Note.158577.1> NLS_LANG Explained (How Does Client-Server Character Conversion Work?) [NOTE:140014.1] ALERT: Oracle8/8i to Oracle9i using New "AL16UTF16" [NOTE:159657.1] Complete Upgrade Checklist for Manual Upgrades from 8.X / 9.0.1 to Oracle9i (incl. 9.2) [NOTE:124721.1] Migrating an Applications Installation to a New Character Set Oracle8i National Language Support Guide Oracle8i Release 3 (8.1.7) Readme - Section 18.12 "Restricted ALTER DATABASE CHARACTER SET Command Support (CLOB and NCLOB)" Oracle8i Documentation Addendum, Release 3 (8.1.7) - Chapter 3 "New Character Set Scanner Utility" Oracle8i Application Developer's Guide - Large Objects (LOBs), Release 2 - Chapter 2 "Basic Components" Oracle8 Application Developer's Guide, Release 8.0 - Chapter 6 "Large Objects (LOBs)", Section "Introduction to LOBs" Oracle9i Globalization Guide, Release 1 (9.0.1) Oracle9i Database Globalization Guide, Release 2 (9.2) For further NLS / Globalization information you may start here: [NOTE:150091.1] Globalization Technology (NLS) Library index .
     Copyright (c) 1995,2000 Oracle Corporation. All Rights Reserved. Legal Notices and Terms of Use.
Joel P�rez

Changing DB character set for only one schema

We are interested in changing the characterset of only one user from Western European to AL32UTF8.
Could you please verify if the following steps will be correct to do the same.
1. Run CSScan on the one user
2. Fix any issues
3. Export that one user (with NLS_LANG set to <your old database character set>)
4. Create a new database in the AL32UTF8 character set
5. Import that one user into the new database (with NLS_LANG set to <your old database character set>)

Actually your title is a little incorrect. You are not changing CS for only one schema in existing DB which is not possible. You are trying to migrate a schema to new CS DB. Which is totally doable and your approach is mostly correct.
Database Character Set Scanner provide user scan mode
http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/ch12scanner.htm#i1006013
Mostly the issue could be data truncation, especially if you have column defined using char or varchar2 vs nchar and nvarchar2
because char/varchar is defined in bytes, AL32UTF8 is multi-bytes char set, some character of your old data could saved more than 1 bytes in new DB and can't fit into the column size.

Query distributed database with different character sets.

Hello experts, this is my situation:
I have two databases A and B, the same version 11.1.0.7, the same OS Suse Linux Enterprise 10 but with different character sets, A has WE8MSWIN1252 while B has AL32UTF8. The database B is my XML DB repository so there I have some XML type tables. I need to query this tables from the database A using a dblink and in fact I have done that but the XML content is trasformed due to the different character sets between the databases. Some time there are data loss and some time there are data missmatch.
Is there any way to query the tables stored in the database B without problems? I do not know if the following is correct: Maybe I can set the character set for the session in the database A during the time it query the database B. That is, change the character set in fly at session level.
Do you have any special suggestion?
I hope you can help me, thank you in advance.

The Globalization Support Guide for 11.1.0.7 has a chapter on character set migration that should be helpful. AL32UTF8 is a superset of WE8MSWIN1252 but it is not a strict superset. That is, it doesn't meet the second prong of the test in the documentation
The new character set is a strict superset of the current character set if:
Each and every character in the current character set is available in the new character set.
Each and every character in the current character set has the same code point value in the new character set. For example, many character sets are strict supersets of US7ASCII.Exporting the data from the A, changing the character set (or creating a new database with the AL32UTF8 character set), and then importing the data may be the easiest approach in your case.
Justin
Edited by: Justin Cave on Jan 13, 2011 12:08 PM

NLS character set

Hi,
We have datawarehouse environment..
Currently the NLS Character set in our database is WE8MSWIN1252 which is non multibyte character set.But since this is a datawarehouse environment datawill be coming from source which is multi byte character set.Could you please let us know whether this will be supported in WE8MSWIN1252 character set or not??
Thanks,
Nab

user10124609 wrote:
For changing the NLS character set by export and import do we need to install the database again???yes,you can create new database with Unicode character set and can import there.But for full steps please refer
http://download.oracle.com/docs/cd/E11882_01/server.112/e10729/ch11charsetmig.htm#CEGDHJFF
Changing the Database Character Set ( NLS_CHARACTERSET ) [ID 225912.1]
Changing the Database Character Set - Frequently Asked Questions [ID 227337.1]
Edited by: Chinar on Nov 29, 2010 3:21 AM

Character set conversion problem when importing application with script.

Our database has character set: WE8MSWIN1252
We have a region with the following title: Kopiëren. The ë is stored as character 235 in the database.
When I make an application export the file is in UTF-8. The ë is now stored as hex C3 AB in this file.
When importing the application using the Apex tool, the ë is again stored as character 235 in the database.
In our installation script we use some code to load the application. It look something like this:
declare
begin
   -- Determine workspace ID
   apex_application_install.set_workspace_id(l_workspace_id);
   -- Determine app ID
   apex_application_install.set_application_id(l_app_id);
   apex_application_install.generate_offset;
   apex_application_install.set_schema(l_schema);
   apex_application_install.set_application_alias(l_schema);
   l_app_id := apex_application_install.get_application_id;
end;
@..\apex\f200.sqlThis works fine except that no character set conversion takes place. The UTF-8 character is placed in the database so our region has as title: KopiÃ«ren
Is there a way to fix this?

Hi Rene,
The character set portion of your local NLS_LANG environment variable should be AL32UTF8, and this should be set prior to you importing your application via SQL*Plus.
Joel

UTF/Japanese character set and my application

Blankfellaws...
a simple query about the internationalization of an enterprise application..
I have a considerably large application running as 4 layers.. namely..
1) presentation layer - I have a servlet here
2) business layer - I have an EJB container here with EJBs
3) messaging layer - I have either Weblogic JMS here in which case it is an
application server or I will have MQSeries in which case it will be a
different machine all together
4) adapter layer - something like a connector layer with some specific or
rather customized modules which can talk to enterprise repositories
The Database has few messages in UTF format.. and they are Japanese
characters
My requirement : I need thos messages to be picked up from the database by
the business layer and passed on to the client screen which is a web browser
through the presentation layer.
What are the various points to be noted to get this done?
Where and all I need to set the character set and what should be the ideal
character set to be used to support maximum characters?
Are there anything specifically to be done in my application code regarding
this?
Are these just the matter of setting the character sets in the application
servers / web servers / web browsers?
Please enlighten me on these areas as am into something similar to this and
trying to figure out what's wrong in my current application. When the data
comes to the screen through my application, it looks corrupted. But the asme
message when read through a simple servlet, displays them without a problem.
Am confused!!
Thanks in advance
Manesh

Hello Manesh,
For the database I would recommend using UTF-8.
As for the character problems, could you elaborate which version of WebLogic
are you using and what is the nature of the problem.
If your problem is that of displaying the characters from the db and are
using JSP, you could try putting
<%@ page language="java" contentType="text/html; charset=UTF-8"%> on the
first line,
or if a servlet .... response.setContentType("text/html; charset=UTF-8");
Also to automatically select the correct charset by the browser, you will
have to include
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> in the
jsp.
You could replace the "UTF-8" with other charsets you are using.
I hope this helps...
David.
"m a n E s h" <[email protected]> wrote in message
news:[email protected]...
Blankfellaws...
a simple query about the internationalization of an enterpriseapplication..
>
I have a considerably large application running as 4 layers.. namely..
1) presentation layer - I have a servlet here
2) business layer - I have an EJB container here with EJBs
3) messaging layer - I have either Weblogic JMS here in which case it isan
application server or I will have MQSeries in which case it will be a
different machine all together
4) adapter layer - something like a connector layer with some specific or
rather customized modules which can talk to enterprise repositories
The Database has few messages in UTF format.. and they are Japanese
characters
My requirement : I need thos messages to be picked up from the database by
the business layer and passed on to the client screen which is a webbrowser
through the presentation layer.
What are the various points to be noted to get this done?
Where and all I need to set the character set and what should be the ideal
character set to be used to support maximum characters?
Are there anything specifically to be done in my application coderegarding
this?
Are these just the matter of setting the character sets in the application
servers / web servers / web browsers?
Please enlighten me on these areas as am into something similar to thisand
trying to figure out what's wrong in my current application. When the data
comes to the screen through my application, it looks corrupted. But theasme
message when read through a simple servlet, displays them without aproblem.
Am confused!!
Thanks in advance
Manesh

Import시 character set 문제, OORA-01435, IMP-00008 에러에 의해 중단되었습니다. 조언을 부탁합니다.

안녕하세요,
아래와 같이 import를 하려고 하는데 에러가 나면서 중단되었습니다.
C:\temp>imp userid=system/1234 file=c:\temp\usr_lms2-TS_LMS_DEV_D1.dmp FULL=y
에러메시지는 아래와 같습니다.
참고로, export 했던 어떤 database에는 usr_lms2 계정이 있었고,
import하려는 이 database에는 그 계정이 없어서 usr_lms2 계정을 생성하고 import를 실행했습니다.
질문1: 아래의 character set과 관련된 메시지는 정상적인것인지 궁금합니다.
질문2: ORA-01435: user does not exist라는 에러는 왜 발생할까요?
질문3: IMP-00008: unrecognized statement in the export file 에러는 dump 화일 자체에 문제가 있다는 말인가요?
해결방법을 알려주시면 좋겠습니다.
Import: Release 11.2.0.2.0 - Production on 목 3월 28 10:00:38 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production
Export file created by EXPORT:V10.02.01 via conventional path
import done in KO16MSWIN949 character set and AL16UTF16 NCHAR character set <-------- ?
import server uses AL32UTF8 character set (possible charset conversion) <-------- ?
export server uses UTF8 NCHAR character set (possible ncharset conversion) <-------- ?
. importing SYSTEM's objects into SYSTEM
. importing USR_LMS2's objects into USR_LMS2
IMP-00003: ORACLE error 1435 encountered <-------------------- 에러
ORA-01435: user does not exist <--------------------- 에러
IMP-00008: unrecognized statement in the export file: <-------------------- 에러
Import terminated successfully with warnings.
감사합니다.

Import dump from a satabase with a different character set

My database has this character set:
select * from database_properties:
NLS_CHARACTERSET AL32UTF8 Character set
NLS_NCHAR_CHARACTERSET AL16UTF16 NCHAR Character set
I need to import a dump from a database with WE8MSWIN1252 character set.
After the import I have seet that some character in the table are wrog:
I see this simbol " " insted of this "à".
How can I solve the problem?
The nls_lang variable on my os is: NLS_LANG=ITALIAN_ITALY.AL32UTF8
I work with oracle 10.0.4 on linux
Message was edited by:
user613483

I have read thos doc on metalink: Note:227332.1
I also tried to set nls_lang = NLS_LANG=ITALIAN_ITALY.WE8MSWIN1252
and then I execute the import command.
BUt didn't work.

Specifying character set on application import

Similar Messages

Maybe you are looking for