Character Set Scanner Download

Multiple attempts to download and 'untar/uncompress' the file yields checksum errors. The downloads were for Solaris, both 32 and 64 bit (V9.2). Any way to have these posted files checked?

Pl see MOS Doc 745809.1 (Installing and configuring Csscan in 10g and 11g (Database Character Set Scanner)
HTH
Srini

Similar Messages

Please remove/clarify download for "Oracle8 8.0.6 Character set scanner"

All Oracle documentation says that the first 0.0 version of Character set scanner was supplied with 8.1.7.0 s/w of the database (also see Note:179843.1 - Versioning of the Character Set Scanner).
The OTN download site provides a link (broken link) to csscan of version 1.0 for "Oracle8 8.0.6 Character set scanner for Solaris" at
http://otn.oracle.com/software/tech/globalization/htdocs/utilsoft.html#10
that confuses customers.
As the download link is broken, it is impossible to check what executables this link really leads to.
Please either document this exception somewhere that csscan is in fact available for 8.0.6 database, and why this is true ONLY on Solaris,
or
simply remove the link if created by mistake.
Thank you,
Svetlana Grove
Technical Specialist

The first version of CSSCAN was shipped with 8.1.7 of the database on all Oracle RDBMS platforms. Due to customer demands, backports were made available for 8.1.6 (NT and Solaris) and 8.0.6 (Solaris) also.
We decided to make these pre-8.1.7 CSSCAN available for download on OTN as well.
The download links are not broken. There is a policy in place for Oracle employees, they are restricted from downloading between 6am and 6pm US-PST on business days.

Download Oracle 10g Character set scanner for Solaris

http://www.oracle.com/technology/software/tech/globalization/index.html
the above link contains only the oracle 9i Character set scanner but I need the Oracle 10g Character set scanner for Solaris
please assist me.

Pl see MOS Doc 745809.1 (Installing and configuring Csscan in 10g and 11g (Database Character Set Scanner)
HTH
Srini

Character Set Scanner utility for HP Open Alpha VMS

I would like to know if there are any character set scanner utilities available for Oracle 817 and 920 for HP Open Alpha VMS 7.3-1

Please post this question in the Downloads forum.
The URL is:
Downloads Issues

USING THE CHARACTER SET SCANNER

How can I find and download the Character Set Scanner utility mentioned in MetaLink document # 66320.1.
Thanks
Pratap

I would like to know if there exists a database character set
scanner for ORACLE816. If not, can I use the ORACLE817 scanner
to scan my ORACLE816 database?Check out the Globalization Support Home page
http://technet.oracle.com/tech/globalization/content.html and go
to the scanner download page for more info.
Is it important to use a scanner if I am converting my database
from, say, WE8ISO8859P1 character set to UTF8? Yes definitely. The scanner will identify
1. If you have any invalid WE8ISO8859P1 data in your database ,
these will be lost during the character set conversion process.
2. If there are any data cell expansions, so that column widths
can be expanded to cater for the new sizing.
3. Area of possible character set conversion and truncation of
data.
Can I assume that a database UTF8 will automatically store all
my original characters correctly?UTF8 can store all the characters from WE8ISO8859P1 ,and it can
be stored correctly if your NLS configuration is correct . The
key is your client NLS_LANG character set setting .
I have a client with NLS_LANG set to UFT8. When I exported my
database (in WE8ISO8859P1) from my client, the export was done
in the client's setting i.e. UTF8. Can I assume that the
conversion was done at the time of export itself?Yes, your assumption is correct.

Oracle 8.0.6 & 8.1.6 Character set scanners available for download

The latest version of the character set scanner version 1.0
(based on the 9.0.1 version) is now available on OTN. Oracle has
backported this utility to the following RDBMS releases 8.0.6
(Solaris), 8.1.6 (NT, Solaris) and 8.1.7 (NT, Solaris) .
For more information, please refer to the following URL
http://otn.oracle.com/tech/globalization/content.html

Please feel free to provide any feedback (Bugs, enhancements
etc.) that you may have on the character set scanner in the
discussion forum.

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.

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

How to set or change character set for Oracle 10 XE

Installing via RPM on Linux.
I need to have my database set to use UTF8 and WE8ISO8859P15 as the character set and national character set. (Think those are in the right order. If not, it's the opposite.)
If I do a standard "yum localinstall rpm-file-name," it installs Oracle. I then run the "/etc/init.d/oracle-xe configure" command to set my ports.
Every time I do this, I end up with AL32/AL16 character sets.
I finally hardcoded ISO-8859-15 as the Linux 'locale' character set and set this in the various bash profile config files. Now, I end up with WE8MSWIN1252 as the character set and AL16UTF16 as the national character set.
I've tried editing the createdb.sh script to hard code the character set types and then copied that file over the original while the RPM is still installing. I've tried editing the nls_lang.sh script to hard code the settings there and copied over the original shell script while the RPM is still installing.
Doesn't matter.
HOW can I do this? If I wait until after the RPM is installed and try running the createdb.sh file, then it ends up creating a database but not doing everything properly. I end up missing pfiles or spfiles. Various errors crop up.
If I try to change them from the sql command line, I am told that the new character set must be a superset of the old one. It fails.
I'm new to Oracle, so I'm treading water that's uncharted. In short, I need community help. It's important to the app I'm running and attempting to migrate from to maintain these character sets.
Thanks.

I don't think you can change Oracle XE character set. When downloading Oracle XE you must choose to download:
- either the Universal Edition using AL32UTF8
- or the Western Euopean Edition using WE8MSWIN1252.
See http://download.oracle.com/docs/cd/B25329_01/doc/install.102/b25144/toc.htm#BABJACJJ
If you really need UTF8 instead of AL32UTF8 you need to use Oracle Standard Edition or Oracle Entreprise Edition:
these editions allow to select database character set at database creation time which is not really possible with Oracle XE
Note that changing environment variable NLS_LANG has nothing to do with changing database character set:
http://download.oracle.com/docs/cd/B25329_01/doc/install.102/b25144/toc.htm#BABBGFIC

How to change the character set?

Platform is win2000 and oracle 8.17. I need to write data in Bulragian. Automatic character converter in oracle didn't work! Database is created already!
Is there any function in pl/sql or Java that can convert character set in cl8mswin1251? When I read the data from database there are only ?????
Thank you in advance!

I'm not sure what you're asking here. "Will it be ok" for what?
Assuming
- you read the chapter I linked to,
- ran the character set scanner,
- the character set scanner indicated that all your existing data is properly encoded ISO 8859-1
- the character set scanner indicated that all the ISO 8859-1 data could be converted to Windows-1252
- all the national character set data was properly encoded in whatever national character set the database had
- you did the export properly
- you did the import properly
- your client NLS_LANG settings are all correct
then sure, everything should be OK.
If you skipped one of these steps, I would again strongly encourage you to read the chapter I linked to originally as well as the Metalink article others have pointed you to.
Justin

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

Database character set migration rules

We have an application which migrates various entities from one database to the other. These databases could have different character sets. The migration process is automated. What character set rules should we follow while migration? Can we use the character set scanner is some automated way?
Does ORACLE publish a comprehensive list of subsets and supersets? (and I am NOT talking about strict subsets and supersets) I know that you have a whitepaper which has some rules but that is not a complete set. Any help would be much appreciated. This is an urgent requirement.

There is no simple answer as this is a complex process. You make reference to having looked at a whitepaper on this subject so I assume you know that your application will likely need to dynamically set the nls_lang setting so that proper conversion can take place on the database.
To find what character sets are subsets or supersets of what character sets?
A) The only listing available is in the 8.1.7 Document addendum shipped with the rdbms CD. This document can be found on the web at:
http://technet.oracle.com/docs/products/oracle8i/doc_index.htm
There is no real elegant way to determine possible lossy data situations programmically. Using the scanner to detect within your program whether proper conversion will take place might be possible. There is a documented v$ table that is updated when the scanner is run that could be examined
via SQL in your program to detect lossy data and truncation. You could also possibly use the PL/SQL convert function to detect lossy data. Something like if 'string' = convert('string', us7ascii, WE8MSWIN1252) then ....
Hope this helps.

Metadata character set translation

Hi does any one have an idea how to have your Aperture metadata info exported in the CP 1252 encoding? (Windows Western Europe). (Standard is MAC encoding.)
All my accents in French, German, Spanish and Dutch words come out garbled when I upload my photos to my photo agencies, or my web based Photoshelter archive.
I've tried a lot. So far my only solution is to export my files. Open them in FotoStation which has a conversion function. This is a lot of work though since adding and changing keywords in that program is extremely user unfriendly.
Any advice welcome!
Ronald

We bought SAP R3 system that uses base with WE8DEC set but saves character data in CL8ISO8859P5 for Russian languageI understand your configuration/requirement. The supported way for you to do this is to change your database character set to match the encoding of the data in the database. If you are sure they are all Russian data in CL8ISO8859P5 encoding formats (The Character set scanner utility shipped in 8.1.7 can assist you in verifying the data inside your db) .
Since your Oracle db supports SAP R3 , it is better if you contact SAP on whether they support the changing the db chacter set and the steps involved .

ORA-12712 error while changing nls character set to AL32UTF8

Hi,
It is strongly recommend to use database character set AL32UTF8 when ever a database is going to used with our XML capabilities. The database character set in the installed DB is WE8MSWIN1252. For making use of XML DB features, I need to change it to AL32UTF8. But, when I try doing this, I'm getting ORA-12712: new character set must be a superset of old character set. Is there a way to solve this issue?
Thanks in advance,
Divya.

Hi,
a change from we8mswin1252 to al32utf8 is not directly possible. This is because al32utf is not a binary superset of we8mswin1252.
There are 2 options:
- use full export and import
- Use of the Alter in a sort of restricted way
The method you can choose depends on the characters in the database, is it only ASCII then the second one can work, in other cases the first one is needed.
It is all described in the Support Note 260192.1, "Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode)". Get it from the support/metalink site.
You can also read the chapters about this issue in the Globalization Guide: [url http://download.oracle.com/docs/cd/E11882_01/server.112/e10729/ch11charsetmig.htm#g1011430]Change characterset.
Herald ten Dam
http://htendam.wordpress.com

Oracle XE and character set

Hello all,
I installed Oracle XE on RHEL 4 Linux and I found out that database character set is AL32UTF8. Does anyone know why oracle choose this character set? Maybe because of NLS_LANG env variable? Is it possible to change it to EE8ISO8859P2? Since database is still empty I can drop it and crate new database.
Do you think it is possible to set some env variables and do new oracle xe instalation including database with iso charset?
I want to have EE8ISO8859P2 charset because of doing exp/imp from another oracle iso db to oracle xe and it is much easier to do this without charset conversion.
Any help will be appreciated.
regards,
Miha

When you download XE, you have a choice - take the 'western european' character set download, or the 'unicode' download.
No other choices.
Join us over in the XE forum where people have discussed this and found workarounds. Info about finding that forum at Re: Oracle XE Installation failed

Character Set Scanner Download

Similar Messages

Maybe you are looking for