MultiByte Character Set/Large Object

I am trying to connect a SQL Server 7 and to an Oracle version 8
database system, and have discovered that SQL Server 7 has no support for the new datatypes added in version 8 of Oracle. Is there anything on the Oracle side of things that could take over the exchange of data?
Thanks

I have both the most recent Microsoft OBDC Connection to Oracle and and the one provided by Oracle that came with the 8.1 client install. They both work perfectly fine to create a Data Transformation Services (DTS) package in SQL Server. Up until you hit one of the new 8.0 fields in Oracle.
On Microsoft's MSDN site they spell out what fields they don't support for DTS, and they are the ones I need to use. I wrote s very small VB application to see how it handled the datatype, and it looked fine. If I have to go that route, I will. But a much cleaner solution would be nice.

Similar Messages

9iLite and multibyte character set support

Does 9iLite support a character set that will allow for accented characters?
for example: i

"NLS Character Integrity Issues for Consolidator
When Mobile Sync synchronizes with an Oracle database which has a
multibyte character set other than UTF8, the character integrity issue
occurs. Mobile Sync retrieves data from the server database through Oracle
8.1.7 OCI JDBC Driver for Oracle9iAS version 1.0.2.2, and 9i for Oracle9iAS
version 2.0. Character sets are converted from database character sets to
UTF8 by Oracle Servers NLS functions. In the code conversion, some
multibyte characters are garbled because of the difference of the character
mapping. This is not a bug of Mobile Sync.
For more Information, see "Character Integrity Issues in NLS Environment"
technical paper on Oracle Technology Network (technet.oracle.com)
Java/SQLJ & JDBC section in Technologies category."
from the Readme file with the media (read the manual I guess)

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

Clarification on Character set migration from US7ASCII to UTF8

Hi,
I need clarification on the below.
I need to migrate the database from US7ASCII to UTF8.
For this I ran csscan for user "TEST" as well as against full database.
Below log is the csscan output against full database. but my application is depended on TEST schema only. Shall I need to migrate SYS objects data as shown below or it's not required?. If required how to migrate these objects data?
Looking forward you help.
USER.TABLE Convertible Exceptional
SYS.METASTYLESHEET 58 TEST.Table_1 9 0
TEST.Table_2 11 0
TEST.Table_3 17 0
TEST.Table_4 11 0
[Distribution of Convertible Data per Column]
USER.TABLE|COLUMN Convertible Exceptional
SYS.METASTYLESHEET|STYLESHEET 58 0
Thanks,
Sankar

I think you need to migrate all schemas data not only one application schema because
the database character set is common to all CHAR, VARCHAR2, LONG and CLOB colums
for any tables in any schema.
In your case (US7ASCII to UTF8), you need to use export/import because:
Another restriction of the ALTER DATABASE CHARACTER SET statement is that it can be used only when the character set migration is between two single-byte character sets or between two multibyte character sets. If the planned character set migration is from a single-byte character set to a multibyte character set, then use the Export and Import utilities.
(see http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96529/ch10.htm#1009904)

Java.sql.SQLException: Non supported character set: oracle-character-set-17

Hi,
i am trying to execute an Oracle procedure from JDBC. The procedure accepts a Nested table as an input parameter. Definition of the nested table is given below.
Database – Oracle 10g.
Application Server – JBOSS 4.2.1
I get the following exception._
java.sql.SQLException: Non supported character set: oracle-character-set-178
at oracle.gss.util.NLSError.throwSQLException(NLSError.java:46)
I. JDBC Code_
Session s = HibernateUtil.getSession();
Transaction tr = s.beginTransaction();
con=s.connection();
oraConn = (OracleConnection) con.getMetaData().getConnection();
TableObject obj=new TableObject();
obj.setId(new Integer(123));//Tested ok, stroing in DB
obj.setDescr("test"); // this line throwing error
obj.setCre_user(new Integer(456));
obj.setUpd_user(new Integer(789));
obj.setXfr_flag("Y");
ArrayList al=new ArrayList();
al.add(obj);
Object[] objAray = al.toArray();
ArrayDescriptor arrayDescriptor =ArrayDescriptor.createDescriptor("T_TEST_SYN", oraConn);
ARRAY oracleArray = new ARRAY(arrayDescriptor, oraConn, objAray);
cs = (OracleCallableStatement)oraConn.prepareCall("call PKG_OBJ_TEST.accept_ui_input(?) ");
cs.setArray(1, oracleArray);
cs.execute();
tr.commit();
public class TableObject implements SQLData{
private String sql_type = "T_OBJ_TEST";
private int id;
private String descr;
//private Date cre_date;
private int cre_user;
//private Date upd_date;
private int upd_user;
private String xfr_flag;
public TableObject()
public TableObject (int id,String descr,int cre_user,int upd_user,String xfr_flag)
// this.sql_type = sql_type;
this.id = id;
this.descr = descr;
// this.cre_date=cre_date;
this.cre_user=cre_user;
//this.upd_date=upd_date;
this.upd_user=upd_user;
this.xfr_flag=xfr_flag;
public String getSQLTypeName() throws SQLException {
return "T_OBJ_TEST";
public void readSQL(SQLInput stream, String typeName) throws SQLException {
//sql_type = typeName;
id=stream.readInt();
descr=stream.readString();
//cre_date=stream.readDate();
cre_user=stream.readInt();
//upd_date=stream.readDate();
upd_user=stream.readInt();
xfr_flag=stream.readString();
public void writeSQL(SQLOutput stream) throws SQLException {
try {
stream.writeInt(this.id);
System.out.println("Iddddd");
stream.writeString(this.descr);
System.out.println("Desccccccccccccccc"+":"+descr);
//stream.writeDate(cre_date);
stream.writeInt(this.cre_user);
System.out.println("userrrrrrrrrrrr");
//stream.writeDate(upd_date);
stream.writeInt(this.upd_user);
System.out.println("upd uiserrrrrrrrrrr");
stream.writeString(this.xfr_flag);
System.out.println("flagggggggggggggggggggg"+xfr_flag);
}catch (SQLException se) {
System.out.println("Table object sql exception");
se.printStackTrace();
catch (Exception e) {
System.out.println("Table object exception");
* @return the id
public int getId() {
return id;
* @param id the id to set
public void setId(Object obj) {
Integer iobj= (Integer)obj;
this.id =iobj.intValue();
* @return the descr
public String getDescr() {
System.out.println("getDescr "+descr);
return descr;
* @param descr the descr to set
public void setDescr(Object obj) {
System.out.println("setDescr "+obj);
String sobj = (String)obj;
this.descr=sobj.toString();
System.out.println("setDescr "+obj);
* @return the cre_user
public int getCre_user() {
return cre_user;
* @param cre_user the cre_user to set
public void setCre_user(Object obj) {
Integer iobj=(Integer)obj;
this.cre_user = iobj.intValue();
* @return the upd_user
public int getUpd_user() {
return upd_user;
* @param upd_user the upd_user to set
public void setUpd_user(Object obj) {
Integer iobj=(Integer)obj;
this.upd_user = iobj.intValue();
* @return the xfr_flag
public String getXfr_flag() {
return xfr_flag;
* @param xfr_flag the xfr_flag to set
public void setXfr_flag(Object obj) {
this.xfr_flag = (String)xfr_flag;
II. Oracle database object details
Details of Object and Nested table created in the database.
T_TEST_SYN is a public synonym created for t_tab_obj_test
CREATE OR REPLACE TYPE t_obj_test as object (
id number(10),
descr varchar2(100),
--cre_date date,
cre_user number(10),
--upd_date date,
upd_user number(10),
xfr_flag varchar2(1),
CONSTRUCTOR FUNCTION t_obj_test ( id IN NUMBER DEFAULT NULL,
descr IN varchar2 default null,
--cre_date in date      default null,
cre_user in number default null,
--upd_date in date      default null,
upd_user in number default null,
xfr_flag in varchar2 default null ) RETURN SELF AS RESULT ) ;
CREATE OR REPLACE TYPE BODY t_obj_test as
CONSTRUCTOR FUNCTION t_obj_test ( id IN NUMBER DEFAULT NULL,
descr IN varchar2 default null,
--cre_date in date      default null,
cre_user in number default null,
--upd_date in date      default null,
upd_user in number default null,
xfr_flag in varchar2 default null ) RETURN SELF AS RESULT IS
BEGIN
SELF.id := id ;
SELF.descr := descr ;
--SELF.cre_date := cre_date ;
SELF.cre_user := cre_user ;
--SELF.upd_date := cre_date ;
SELF.upd_user := cre_user ;
SELF.xfr_flag := xfr_flag ;
RETURN ;
END ;
END ;
CREATE OR REPLACE TYPE t_tab_obj_test AS TABLE OF t_obj_test ;
CREATE OR REPLACE PACKAGE BODY PKG_OBJ_TEST AS
PROCEDURE accept_ui_input ( p_tab_obj_test in T_TAB_OBJ_TEST ) IS
BEGIN
FOR row IN p_tab_obj_test.First .. p_tab_obj_test.LAST
LOOP
INSERT INTO OBJ_TEST ( ID,
DESCR,
CRE_DATE,
CRE_USER,
UPD_DATE,
UPD_USER,
XFR_FLAG )
VALUES ( p_tab_obj_test(row).ID,
p_tab_obj_test(row).DESCR,
NULL,
p_tab_obj_test(row).CRE_USER,
NULL,
p_tab_obj_test(row).UPD_USER,
p_tab_obj_test(row).XFR_FLAG ) ;
END LOOP ;
COMMIT ;
END accept_ui_input ;
END PKG_OBJ_TEST;
/

Check your CLASSPATH enviroment variable. Try to add something like c:\Ora10g\jlib\orai18n.jar.
From "JDBC Developers Guide and Reference":
orai18n.jar
Contains classes for globalization and multibyte character sets support
This solved the same error in my case.

How to review implication of database character set change on PL/SQL code?

Hi,
We are converting WE8ISO8859P1 oracle db characterset to AL32UTF8. Before conversion, i want to check implication on PL/SQL code for byte based SQL functions.
What all points to consider while checking implications on PL/SQL code?
I could find 3 methods on google surfing, SUBSTRB, LENGTHB, INSTRB. What do I check if these methods are used in PL/SQL code?
What do we check if SUBSTR and LENGTH functions are being used in PL/SQl code?
What all other methods should I check?
What do I check in PL/SQL if varchar and char type declarations exist in code?
How do i check implication of database characterset change to AL32UTF8 for byte bases SQL function.
Thanks in Advance.
Regards,
Rashmi

There is no quick answer. Generally, the problem with PL/SQL code is that once you migrate from a single-byte character set (like WE8ISO8859P1) to a multibyte character set (like AL32UTF8), you can no longer assume that one character is one byte. Traditionally, column and PL/SQL variable lengths are expressed in bytes. Therefore, the same string of Western European accented letters may no longer fit into a column or variable after migration, as it may now be longer than the old limit (2 bytes per accented letter compared to 1 byte previously). Depending on how you dealt with column lengths during the migration, for example, if you migrated them to character length semantics, and depending on how relevant columns were declared (%TYPE vs explicit size), you may need to adjust maximum lengths of variables to accommodate longer strings.
The use of SUBSTR, INSTR, and LENGTH and their byte equivalents needs to be reviewed. You need to understand what the functions are used for. If the SUBSTR function is used to truncate a string to a maximum length of a variable, you may need to change it to SUBSTRB, if the variable's length constraint is still declared in bytes. However, if the variable's maximum length is now expressed in characters, SUBSTR needs to be used. However, if SUBSTR is used to extract a functional part of a string (e.g. during parsing), possibly based on result from INSTR, then you should use SUBSTR and INSTR independently of the database character set -- characters matter here, not bytes. On the other hand, if SUBSTR is used to extract a field in a SQL*Loader-like fixed-format input file (e.g. read with UTL_FILE), you may need to standardize on SUBSTRB to make sure that fields are extracted correctly based on defined byte boundaries.
As you see, there is universal recipe on handling these functions. Their use needs to be reviewed and understood and it should be decided if they are fine as-is or if they need to be replaced with other forms.
Thanks,
Sergiusz

It's possible to convert 'WE8MSWIN1252' character to chinese character set?

Hi All,
Is anyone know how to convert "WE8MSWIN1252" character to chinese character set in order to display chinese word in oracle apex?
My problem is i can't display chinese character set in oracle apex. The chinese field is showed like °×ÑªÇò¼ÆÊý. I'm using WE8MSWIN1252 database character set.
I'm wondering it's possible to show character word?
I'm appreciating if anyone have a good solution to share with me.
Thanks a lot in advance!
Edited by: Apex Junior on Jul 16, 2010 2:18 PM

WE8 is a Western European character set. If you wish to store and access a globalized multibyte character set you must have a database that supports it: You don't have one at the moment.
Given this is Apex I'd suggest you read the docs and reinstall.
Alternatively you could try CSSCAN and CSALTER and perhaps you can make the change but be very careful and have a good backup before you try.
http://www.morganslibrary.org/reference/character_sets.html

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

Oracle character set confused

Dear all:
We installed the Latest NW7.0 SR3 for EP&EP core for my Portal application. After that ,i found that our oralce default character set is UTF-8. But some of other Java codes(Iviews,pages..which we developed on Tomcat envionment.)are based in the environment of Oracle character set ZHS16GBK. So iam confused that The NW7.0 SR3 can only install in 64bit OS and a Unicode system. Can i change the oracle character set from UTF8 to ZHS16GBK. Or how can i install the SAP system whose oracle basing on character set ZHS16GBK.
Thanks everyone.

Hello Shao,
ok lets clarify some things at the beginning.
A SAP Java system is not "only using" the database characterset, it is using the national characterset (column types NCHAR, NVARCHAR2, NCLOB). You can check this by reading sapnote #669902.
You can also check sapnote #456968/#695899 for the supported super sets:
=> As of SAP Web AS Release 7.00 and Oracle client 10g, multibyte character sets are no longer supported
With these informations you can not use ZHS16GBK.
> But some of other Java codes(Iviews,pages..which we developed on Tomcat envionment.)are based in the environment of Oracle character set ZHS16GBK
Sorry but i don't understand this sentence.
What is your problem with the java code? Do you have custom tables with column types CHAR,VARCHAR2 or CLOB?
Regards
Stefan

Add new Character Set (Arabic AR8MSWIN1256) to existing 11gR1 (Windows)

Hi all
I have an installed 11gR1 database on Windows 2008 platform with default character set of AMERICAN_AMERICA.WE8MSWIN1252.
How do I go about adding another character set (ARABIC_UNITED ARAB EMIRATES.AR8MSWIN1256) to the database so that it support storage/retrieval of arabic characters as well as English? Is this possible?
Or do I have to recreate the database with both character sets selected at creation time?
Cheers.

You cannot add a character set to an Oracle database. Your choices are (in increasing order of recommendation)
1) Use the NVARCHAR2 data type to store Arabic data. NVARCHAR2 character set is usually AL16UTF16, so you can store any language there. Cons: special handling must be programmed/configured in applications to use NVARCHAR2; some components, like Oracle Text, do not support NVARCHAR2 data type.
2) Migrate the character set of your database to AR8MSWIN1256. If your database is freshly created and empty, just drop it and create a new one. If the database is not empty but you have only pure ASCII data in the whole database, e.g. no special Windows characters, you can use csscan+csalter.plb to migrate. Search this forum and Oracle Database Globalization Support Guide for instructions.
3) Migrate the character set of your database to AL32UTF8. The migration conditions are as in 2) above. AL32UTF8 is Unicode and you can store Arabic, English, French, and whatever your want. One disadvantage: Unicode is obviously a multibyte character set and Arabic requires more space in Unicode compared to AR8MSWIN1256, which is single-byte. But in AR8MSWIN1256 you cannot properly store Persian and some other languages written with Arabic script. You cannot store French, German, Russian, etc. either.
-- Sergiusz

Character Set questions on setup

I am trying to determine what the best setup recommendations are for creating non_English Oracle 10g databases. I have not had much experience building databases for non_English locales, so this is getting a little overwhelming as I have been researching Oracle's Database Globalization Support Guide. Obviously it has a wealth of information and I am trying to determine what applies to us at this point and time.
Generally when someone buys our product they create a new Oracle instance for our app. I need to be able to recommend proper database settings/parameters for potential global customers who purchase our software to run on Oracle.
Currently my biggest question is what to recommend for the Database Characterset on db creation. Currently the DB Character Set we recommend (for standard U.S. installs on Windows) is the default WE8MSWIN1252 character set. Our application is non-unicode. It has been recommended to me from an outside consultant that we "must" use UTF-8 for DB and National Character Set settings, as opposed to WE8MSWIN1252 or WE8ISO8859P1. I should mention that our focus at this point and time is getting a solution for French, German, and Spanish. We are also more concerned about a single language setup than multilanguage - although that is a definite future consideration.
What impact can using UTF-8 as opposed to WE8MSWIN1252 or WE8ISO8859P1 have on a non-unicode application? I hope I am explaining the situation well enough as I am fairly new and still getting to know our application. I am kind of getting thrown into the i18n fire...
Any input is greatly appreciated. Thanks.

Your questions are certainly valid but you have not given any details about your application: what it does, what technologies and access drivers are employed, and what client operating systems are supported. This determines how much effort is required to make the application Unicode-enabled and what are the risks coming from each of the possible approaches.
As long as your application can work with single-byte character sets only and as long as it is not expected to contain multibyte data, and as long as it supports Windows only, the Oracle character set corresponding to relevant Windows ANSI code page is the correct choice. For English, French, German, Spanish, and other Western European languages, WE8MSWIN1252 is right one.
Processing of WE8MSWIN1252 is easier and somehow faster than processing AL32UTF8 (i.e. UTF-8) data. One character corresponds to one byte and this simplifies some aspects of text processing.
On the other hand, world becomes smaller and smaller in the Internet area. Companies that never did any business abroad start to talk to customers around the world because somebody found their website. Western European companies take advantage of the European Union enlargement and start making business in new countries. Therefore, it is dangerous to assume that a company currently interested in a monolingual, single-byte solution will not want to migrate to a multilingual and multibyte solution in few years.
If you follow a few rules in database design and programming, you can run your single-byte application against an AL32UTF8 database, even if you do not get a multilingual system in this way. Such configuration has the huge advantage of avoiding the need of a complex and resource consuming task of migrating the database character set to Unicode in future, when your customer asks for multilingual support. Upgrading binaries of your application to an Unicode-enabled version is usually fast, migrating the database character set is not.
The main rules you should follow are:
1) Use character length semantics to define column and PL/SQL variable lengths, i.e. say VARCHAR2(10 CHAR) instead of VARCHAR2(10 [BYTE]). If you do not want to modify all creation scripts to include the CHAR keyword, issue ALTER SESSION SET NLS_LENGTH_SEMANTICS=CHAR at the beginning of each script. I recommend modifying the scripts.
2) Do not use VARCHAR2 columns longer than 1000 characters, CHAR columns longer than 500 characters, and PL/SQL VARCHAR2/CHAR variables longer than 8190 characters. This guarantees that in the future no AL32UTF8 string will exceed the hard limit of 4000/2000/32760 bytes. Use CLOB for longer text.
3) Use SUBSTR/LENGTH/INSTR in place of SUBSTRB/LENGTHB/INSTRB. Use SUBSTRB/LENGTHB/INSTRB only when dealing with legacy stuff or Data Dictionary that still use byte length semantics.
4) Define the client setting - mainly NLS_LANG - to correctly correspond to the character set processed by your application.
5) Modify interfaces to other databases, if any, to cope with the character length semantics. You do not have to do much if the other databases follow the same rules.
The cost of running the database in Unicode is not high for most languages, though languages that do not use Latin script, such as Russian, Greek, or Japanese, need significantly more storage for the textual data (but only textual data in those languages - this is only some fraction of all data in the database). Processing is slower by a few percent as compared to single-byte character sets (unless a lot of textual processing is performed in the database, in which case the percentage may be higher - benchmark recommended). This costs can be usually compensated by adding some more computing power (GHz and disks). Unless your application needs a VLDB (very large database) and almost saturates the system, you should not notice a big difference.
-- Sergiusz

Import problem due to Character set

I did an export of an entire schema using Original export utility(not Datapump) in 10G Release 1 (10.1.0.3.0). When i tried to import it. I got the error mentioned below. It is something to do with the character set. What settings do i have to give during import to bypass this Character set problem? After taking the export dmp file i deleted the Schema. So i all i've got is the export dmp file.
import done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
import server uses AL32UTF8 character set (possible charset conversion)
. importing MOTORGM's objects into 'MOTORGM2'
. . importing table "SKU_DETAILS" 1872 rows imported
. . importing table "COMP_LLU_DETAILS" 1877 rows imported
. . importing table "SHIP_ROUTING" 0 rows imported
. . importing table "SHIP_ROUTING_CODE" 0 rows imported
. . importing table "AI_DETAILS" 103 rows imported
. . importing table "AI_DETAILS_BKP" 103 rows imported
IMP-00019: row rejected due to ORACLE error 12899.
IMP-00003: ORACLE error 12899 encountered.
ORA-12899: value too large for column "MOTORGM2"."CLASS_REC"(actual: 1017, maximum: 255)
Column1....
Column2....

-- db unicode charset
SQL> create table z_test_unicode (c varchar2(5));
Table created.
SQL> insert into z_test_unicode values('éèîàö');
insert into z_test_unicode values('éèîàö')
ERROR at line 1:
ORA-01401: inserted value too large for column
SQL> insert into z_test_unicode values('é');
1 row created.
SQL> select vsize(c) from z_test_unicode;
VSIZE(C)
3
SQL> insert into z_test_unicode values('éà');
insert into z_test_unicode values('éà')
ERROR at line 1:
ORA-01401: inserted value too large for column
SQL> drop table z_test_unicode
2 /
Table dropped.
-- db without unicode charset
Connected.
SQL> create table z_test_unicode (c varchar2(5));
Table created.
SQL> insert into z_test_unicode values('éèîàö');
1 row created.
SQL> commit;
Commit complete.
SQL> select vsize(c) from z_test_unicode;
VSIZE(C)
5
On possible solution to investigate for this kink of issue :
try to take a look at the init param : nls_lenght_semantics (by default set to Byte) --> to be changed to CHAR
SQL> show parameter semanti
NAME TYPE VALUE
nls_length_semantics string BYTE

How to change the Character Set from AL32UTF8 to WE8DEC

Hello!!
I want to know how to change the character set in the database from AL32UTF8 to WE8DEC.
I tried to use the comand ALTER DATABASE CHARACTER SET but I got an error because WE8DEC is not a superset of AL32UTF8.
I need to import tables from a server that uses WE8DEC. So when I do the import to my server, wich has AL32UTF8 , I can't import the rows that include an Ñ.
So I want to change the caracter set to WE8DEC. How can I do it?
Is it needed to change the language configuration? The remote server has AMERICAN_AMERICA, and my server has MEXICAN SPANISH_MEXICO (both uses text in spanish).
Thanks a lot!!

When you export from WE8DEC server what did you use
for NLS_LANG char set? And when importing?
The export was done in another computer because I can't do the export in the server (I have 10g, and the remote server has 9i and the export is not working). In my server, when I tried to do the import, the NS_LANG value was MEXICAN SPANISH_MEXICO.WE8MSWIN1252.
When I try to import to my database I got the error:
import done in WE8DEC character set and AL16UTF16 NCHAR character set
import server uses AL32UTF8 character set (possible charset conversion)
export client uses WE8MSWIN1252 character set (possible charset conversion)
. importing USRMCR06's objects into PRIMARIZACION
. . importing table "CHG_FONDOS_MARZO_CD_MOR"
IMP-00019: row rejected due to ORACLE error 12899
IMP-00003: ORACLE error 12899 encountered
ORA-12899: value too large for column "PRIMARIZACION"."CHG_FONDOS_MARZO_CD_MOR".
"NOMBRE" (actual: 41, maximum: 40)
Column 1 16623436
Column 2
Column 3 Pymes_1
Column 4

Partial Multibyte Character Error

Hi All,
I am getting following error while running a report in OBIEE 11 G.
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 17001] Oracle Error code: 29275, message: ORA-29275: partial multibyte character at OCI call OCIStmtFetch. [nQSError: 17012] Bulk fetch failed. (HY000)
NLS_LANG Paramters is set at the Oracle database 11.
[NLS_LANGUAGE].[NLS_TERRITORY][NLS_CHARACTERSET]----------->AMERICAN.AMERICA.AL32UTF8
Any help in this.

Hi,
It's seems are you using char function in your report?
If yes, Change the char size .
ex: cast(column name as char).
A. Cast(column name as char(300)).
I am not sure this is what your looking so far.
Award points it is useful.
Thanks,
Satya

Problem with Character Set in Oracle database 10g

Hi,
I tried to import one tablespace into test server. Source server with Oracle 8i and Target server with Oracle database 10g. The error I get is
Import: Release 10.2.0.1.0 - Production on Thu Aug 3 00:20:49 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Username: sys as sysdba
Password:
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Export file created by EXPORT:V08.01.07 via conventional path
About to import transportable tablespace(s) metadata...
import done in WE8DEC character set and AL16UTF16 NCHAR character set
export server uses WE8DEC NCHAR character set (possible ncharset conversion)
. importing SYS's objects into SYS
. importing SYS's objects into SYS
IMP-00017: following statement failed with ORACLE error 19736:
"BEGIN sys.dbms_plugts.beginImport ('8.1.7.4.0',2,'2',NULL,'NULL',67051,25"
"51,2); END;"
IMP-00003: ORACLE error 19736 encountered
ORA-19736: can not plug a tablespace into a database using a different national character set
ORA-06512: at "SYS.DBMS_PLUGTS", line 2386
ORA-06512: at "SYS.DBMS_PLUGTS", line 1946
ORA-06512: at line 1
IMP-00000: Import terminated unsuccessfully
PLZ somebody help in geting resolve this. Has anybody seen this error before.

The solution to this problem is described in MetaLink note #211920.1. But this note is published with LIMITED access as it involves using a hidden parameter.
You can get access to the note through Oracle Support only.
The problem itself is solved generically, if the source database is at least 10.1.0.3 and the target database is 10.2
-- Sergiusz

MultiByte Character Set/Large Object

Similar Messages

Maybe you are looking for