Ora-12704: character set mismatch

I'm trying to insert string data into a nvarchar2 column using jdbc and I keep getting the error, ora-12704: character set mismatch. How do I avoid this without using the translate function? I believe my nls variables are all set correctly. Our software will eventually be in Korean.

Both my database and national character sets are UTF8.
We are trying to design a system
that supports internationalization. Majority
of our customers will be using English but we do have Korean customers. All their data will be in korean. It is my understanding (and I could be wrong) that the korean character set is varying multi-byte. This understanding has lead me to believe I need to define my "character" columns as nchar and nvarchar2. Is this assumption wrong?
Also, my nls_lang environment variable is AMERICAN_AMERICA.UTF8. I'm currently running Oracle 8.1.6. We have received 8.1.7 but I haven't upgraded yet.
Thanks in advance!

Similar Messages

Migration from 9i to 11g Transparent Gateway results in a) ORA-12704: character set mismatch b) ORA-02070: database ... does not support SYS_OP_C2C in this context

Migration from 9i to 11g Transparent Gateway results in a) ORA-12704: character set mismatch b) ORA-02070: database ... does not support SYS_OP_C2C in this context
What Transparent Gateway (TG) 11g configuration steps prevent the following errors?:
a) ORA-12704: character set mismatch
b) ORA-02070: database <DB_link_name> does not support SYS_OP_C2C in this context
Hints:
The current 9i TG works with the existing views and packages. These same db objects will not compile using the new 11g TG.
The db objects are on an Oracle 10g database linked to an SQL Server 2008 R2 database.
Since the 9i TG works I assume a configuration to the 11g TG will get it working same as before. But what...
Is is something controlled by these parameters? (Sorry, I don't know how this stuff works. I'm the application developer. My DBAs setup the Transparent Gateways.):
Parameters in the Gateway Startup Shell script:
    ORA_NLS33
    NLS_LANG
Parameters in the initsid.ora file:
    HS_LANGUAGE
    HS_NLS_DATE_FORMAT
    HS_NLS_DATE_LANGUAGE
I'm avoiding the known workaround to refactor the VIEWS and PACKAGES to contain CAST() statements to explicitly match the data types. A server side fix to the 11g TG is preferred.
Sample code:
a) ORA-12704: character set mismatch
   ... is caused by SQL that works with my 9i TG but not with my 11g TG. It's a snippit from my view that won't compile:
                  select status_code                  -- Oracle VARCHAR2(30)
                  from   ora_app_interfaces
                 UNION
                  select "StatusCode" as status_code -- SQL Server NVARCHAR(30)
                  from   SqlAppInterfaces
   Example workaround that I'm avoiding:
                  select status_code
                  from   ora_app_interfaces
                 UNION
                  select CAST("StatusCode" as VARCHAR(30)) as status_code
                  from   SqlAppInterfaces
b) ORA-02070: database <DB_link_name> does not support SYS_OP_C2C in this context
   A line of code in the procedure that compiles correctly but fails to execute:
           -- Insert into SQL Server from Oracle
           insert into PatientMedRecNum (
              "PatID",         -- SQL Server INT
              "MedRecNum",     -- SQL Server NVARCHAR(11)
              "Hospital")      -- SQL Server NVARCHAR(30)
           values (
              pi_pat_id,       -- Oracle NUMBER
              pi_med_rec_num, -- Oracle VARCHAR2
              pi_hospital);    -- Oracle VARCHAR2
I'd guess the errors are caused by the TG's implicit conversion between the Oracle VARCHAR2 and the SQL Server NVARCHAR... but this works fine on the 9i TG... how do I set it up to work on the 11g TG?
Thanks!

Trace of 11g TG... generating errors due to lack of automatic mapping from SQL NVARCHAR to Oracle NVARCHAR, where the previous 9g TG mapped from SQL NVARCHAR to Oracle VARCHAR2.
Oracle Corporation --- MONDAY    SEP 22 2014 13:35:08.186
Heterogeneous Agent Release
11.2.0.4.0
Oracle Corporation --- MONDAY    SEP 22 2014 13:35:08.186
Version 11.2.0.4.0
Entered hgogprd
HOSGIP for "HS_FDS_TRACE_LEVEL" returned "DEBUG"
Entered hgosdip
setting HS_OPEN_CURSORS to default of 50
setting HS_FDS_RECOVERY_ACCOUNT to default of "RECOVER"
setting HS_FDS_RECOVERY_PWD to default value
setting HS_FDS_TRANSACTION_LOG to default of HS_TRANSACTION_LOG
setting HS_IDLE_TIMEOUT to default of 0
setting HS_FDS_TRANSACTION_ISOLATION to default of "READ_COMMITTED"
setting HS_NLS_NCHAR to default of "UCS2"
setting HS_FDS_TIMESTAMP_MAPPING to default of "DATE"
setting HS_FDS_DATE_MAPPING to default of "DATE"
setting HS_RPC_FETCH_REBLOCKING to default of "ON"
setting HS_FDS_FETCH_ROWS to default of "100"
setting HS_FDS_RESULTSET_SUPPORT to default of "FALSE"
setting HS_FDS_RSET_RETURN_ROWCOUNT to default of "FALSE"
setting HS_FDS_PROC_IS_FUNC to default of "FALSE"
setting HS_FDS_MAP_NCHAR to default of "TRUE"
setting HS_NLS_DATE_FORMAT to default of "YYYY-MM-DD HH24:MI:SS"
setting HS_FDS_REPORT_REAL_AS_DOUBLE to default of "FALSE"
setting HS_LONG_PIECE_TRANSFER_SIZE to default of "65536"
setting HS_SQL_HANDLE_STMT_REUSE to default of "FALSE"
setting HS_FDS_QUERY_DRIVER to default of "FALSE"
setting HS_FDS_SUPPORT_STATISTICS to default of "TRUE"
setting HS_FDS_QUOTE_IDENTIFIER to default of "TRUE"
setting HS_KEEP_REMOTE_COLUMN_SIZE to default of "OFF"
setting HS_FDS_GRAPHIC_TO_MBCS to default of "FALSE"
setting HS_FDS_MBCS_TO_GRAPHIC to default of "FALSE"
setting HS_CALL_NAME_ISP to "gtw$:SQLTables;gtw$:SQLColumns;gtw$:SQLPrimaryKeys;gtw$:SQLForeignKeys;gtw$:SQLProcedures;gtw$:SQLStatistics;gtw$:SQLGetInfo"
setting HS_FDS_DELAYED_OPEN to default of "TRUE"
setting HS_FDS_WORKAROUNDS to default of "0"
setting HS_FDS_ARRAY_EXEC to default of "TRUE"
Exiting hgosdip, rc=0
ORACLE_SID is "xxxDEV"
Product-Info:
Port Rls/Upd:4/0 PrdStat:0
Agent:Oracle Database Gateway for MSSQL
Facility:hsa
Class:MSSQL, ClassVsn:11.2.0.4.0_0019, Instance:xxxDEV
Exiting hgogprd, rc=0
Entered hgoinit
HOCXU_COMP_CSET=1
HOCXU_DRV_CSET=178
HOCXU_DRV_NCHAR=1000
HOCXU_DB_CSET=178
HS_LANGUAGE not specified
rc=1239980 attempting to get LANG environment variable.
HOCXU_SEM_VER=102000
Entered hgolofn at 2014/09/22-13:35:08
RC=-1 from HOSGIP for "PATH"
Setting PATH to "C:\oracle\product\11.2.0\tg_2\dg4msql\driver\lib"
Exiting hgolofn, rc=0 at 2014/09/22-13:35:08
HOSGIP for "HS_OPEN_CURSORS" returned "50"
HOSGIP for "HS_FDS_FETCH_ROWS" returned "100"
HOSGIP for "HS_LONG_PIECE_TRANSFER_SIZE" returned "65536"
HOSGIP for "HS_NLS_NUMERIC_CHARACTER" returned ".,"
HOSGIP for "HS_KEEP_REMOTE_COLUMN_SIZE" returned "OFF"
HOSGIP for "HS_FDS_DELAYED_OPEN" returned "TRUE"
HOSGIP for "HS_FDS_WORKAROUNDS" returned "0"
HOSGIP for "HS_FDS_MBCS_TO_GRAPHIC" returned "FALSE"
HOSGIP for "HS_FDS_GRAPHIC_TO_MBCS" returned "FALSE"
treat_SQLLEN_as_compiled = 1
Exiting hgoinit, rc=0 at 2014/09/22-13:35:08
Entered hgolgon at 2014/09/22-13:35:08
reco:0, name:abaccess, tflag:0
Entered hgosuec at 2014/09/22-13:35:08
uencoding=UTF16
Entered shgosuec at 2014/09/22-13:35:08
Exiting shgosuec, rc=0 at 2014/09/22-13:35:08
shgosuec() returned rc=0
Exiting hgosuec, rc=0 at 2014/09/22-13:35:08
HOSGIP for "HS_FDS_RECOVERY_ACCOUNT" returned "RECOVER"
HOSGIP for "HS_FDS_TRANSACTION_LOG" returned "HS_TRANSACTION_LOG"
HOSGIP for "HS_FDS_TIMESTAMP_MAPPING" returned "DATE"
HOSGIP for "HS_FDS_DATE_MAPPING" returned "DATE"
HOSGIP for "HS_FDS_MAP_NCHAR" returned "TRUE"
HOSGIP for "HS_FDS_RESULTSET_SUPPORT" returned "FALSE"
HOSGIP for "HS_FDS_RSET_RETURN_ROWCOUNT" returned "FALSE"
HOSGIP for "HS_FDS_PROC_IS_FUNC" returned "FALSE"
HOSGIP for "HS_FDS_REPORT_REAL_AS_DOUBLE" returned "FALSE"
HOSGIP for "HS_FDS_DEFAULT_OWNER" returned "dbo"
HOSGIP for "HS_SQL_HANDLE_STMT_REUSE" returned "FALSE"
Entered hgocont at 2014/09/22-13:35:08
HS_FDS_CONNECT_INFO = "sqlserverxxx/sqlinstancexxx/SQL_Server_2008_xxx_DEV"
RC=-1 from HOSGIP for "HS_FDS_CONNECT_STRING"
Entered hgogenconstr at 2014/09/22-13:35:08
dsn: sqlserverxxx/sqlinstancexxx/SQL_Server_2008_xxx_DEV, name:xxx_admin
optn:
Entered hgocip at 2014/09/22-13:35:08
dsn:sqlserverxxx/sqlinstancexxx/SQL_Server_2008_xxx_DEV
Exiting hgocip, rc=0 at 2014/09/22-13:35:08
Entered shgogohn at 2014/09/22-13:35:08
ohn is 'OraGtw11g_home2'
Exiting shgogohn, rc=0 at 2014/09/22-13:35:08
RC=-1 from HOSGIP for "HS_FDS_ENCRYPT_SESSION"
using 0 as default value for "HS_FDS_ENCRYPT_SESSION"
RC=-1 from HOSGIP for "HS_FDS_VALIDATE_SERVER_CERT"
using 1 as default value for "HS_FDS_VALIDATE_SERVER_CERT"
Entered hgocont_OracleCsidToIANA at 2014/09/22-13:35:08
Returning 2252
Exiting hgocont_OracleCsidToIANA at 2014/09/22-13:35:08
Exiting hgogenconstr, rc=0 at 2014/09/22-13:35:08
Entered hgopoer at 2014/09/22-13:35:08
hgopoer, line 231: got native error 5701 and sqlstate 01000; message follows...
[Oracle][ODBC SQL Server Wire Protocol driver][Microsoft SQL Server]Changed database context to 'Xxx_XXX_DEV'. {01000,NativeErr = 5701}[Oracle][ODBC SQL Server Wire Protocol driver][Microsoft SQL Server]Changed language setting to us_english. {01000,NativeErr = 5703}
Exiting hgopoer, rc=0 at 2014/09/22-13:35:08
hgocont, line 2764: calling SqlDriverConnect got sqlstate 01000
Entered hgolosf at 2014/09/22-13:35:08
Exiting hgolosf, rc=0 at 2014/09/22-13:35:08
DriverName:HGmsss23.dll, DriverVer:07.01.0093 (B0098, U0065)
DBMS Name:Microsoft SQL Server, DBMS Version:10.00.2531
Exiting hgocont, rc=0 at 2014/09/22-13:35:08 with error ptr FILE:hgocont.c LINE:2764 ID:SQLDriverConnect
SQLGetInfo returns Y for SQL_CATALOG_NAME
SQLGetInfo returns 128 for SQL_MAX_CATALOG_NAME_LEN
Exiting hgolgon, rc=0 at 2014/09/22-13:35:08
Entered hgoulcp at 2014/09/22-13:35:08
Entered hgowlst at 2014/09/22-13:35:08
Exiting hgowlst, rc=1 at 2014/09/22-13:35:08
SQLGetInfo returns Y for SQL_PROCEDURES
SQLGetInfo returns 0x1f for SQL_OWNER_USAGE
TXN Capable:2, Isolation Option:0xf
SQLGetInfo returns 128 for SQL_MAX_SCHEMA_NAME_LEN
SQLGetInfo returns 128 for SQL_MAX_TABLE_NAME_LEN
SQLGetInfo returns 134 for SQL_MAX_PROCEDURE_NAME_LEN
HOSGIP returned value of "TRUE" for HS_FDS_QUOTE_IDENTIFIER
SQLGetInfo returns " (0x22) for SQL_IDENTIFIER_QUOTE_CHAR
13 instance capabilities will be uploaded
capno:1992, context:0x0001ffff, add-info:        0
capno:3042, context:0x00000000, add-info:        0, translation:"42"
capno:3047, context:0x00000000, add-info:        0, translation:"57"
capno:3049, context:0x00000000, add-info:        0, translation:"59"
capno:3050, context:0x00000000, add-info:        0, translation:"60"
capno:3066, context:0x00000000, add-info:        0
capno:3067, context:0x00000000, add-info:        0
capno:3068, context:0x00000000, add-info:        0
capno:3069, context:0x00000000, add-info:        0
capno:3500, context:0x00000001, add-info:       91, translation:"42"
capno:3501, context:0x00000001, add-info:       93, translation:"57"
capno:3502, context:0x00000001, add-info:      107, translation:"59"
capno:3503, context:0x00000001, add-info:      110, translation:"60"
Exiting hgoulcp, rc=0 at 2014/09/22-13:35:08
Entered hgouldt at 2014/09/22-13:35:08
NO instance DD translations were uploaded
Exiting hgouldt, rc=0 at 2014/09/22-13:35:08
Entered hgobegn at 2014/09/22-13:35:08
tflag:0 , initial:1
hoi:0x12ee18, ttid (len 32) is ...
xxx
xxx
tbid (len 10) is ...
0: 09000F00 0FAC1E00 010A [..........]
Exiting hgobegn, rc=0 at 2014/09/22-13:35:08
Entered hgodtab at 2014/09/22-13:35:08
count:1
table: XXX_INTERFACE
Allocate hoada[0] @ 0000000005F58270
Entered hgopcda at 2014/09/22-13:35:08
Column:1(InterfaceID): dtype:2 (NUMERIC), prc/scl:20/0, nullbl:0, octet:0, sign:1, radix:10
Exiting hgopcda, rc=0 at 2014/09/22-13:35:08
Entered hgopcda at 2014/09/22-13:35:08
Column:2(TableName): dtype:-9 (WVARCHAR), prc/scl:30/0, nullbl:0, octet:60, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/09/22-13:35:08
Entered hgopcda at 2014/09/22-13:35:08
Column:3(TableID): dtype:4 (INTEGER), prc/scl:10/0, nullbl:0, octet:0, sign:1, radix:10
Exiting hgopcda, rc=0 at 2014/09/22-13:35:08
Entered hgopcda at 2014/09/22-13:35:08
Column:4(StatusCode): dtype:-9 (WVARCHAR), prc/scl:30/0, nullbl:0, octet:60, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/09/22-13:35:08
Entered hgopcda at 2014/09/22-13:35:08
Column:5(StatusTimestamp): dtype:93 (TIMESTAMP), prc/scl:23/3, nullbl:0, octet:0, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/09/22-13:35:08
Entered hgopcda at 2014/09/22-13:35:08
Column:6(InterfaceLog): dtype:-9 (WVARCHAR), prc/scl:400/0, nullbl:1, octet:800, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/09/22-13:35:08
The hoada for table XXX_INTERFACE follows...
hgodtab, line 1073: Printing hoada @ 0000000005F58270
MAX:6, ACTUAL:6, BRC:1, WHT=6 (TABLE_DESCRIBE)
hoadaMOD bit-values found (0x40:TREAT_AS_NCHAR,0x400:UNICODE_COLUMN)
DTY NULL-OK LEN MAXBUFLEN   PR/SC CST IND MOD NAME
3 DECIMAL N         22         22 20/ 0    0   0   0 InterfaceID
12 VARCHAR N         60         60 128/ 30 1000   0 440 TableName
4 INTEGER N          4 4   0/ 0    0   0   0 TableID
12 VARCHAR N         60         60 128/ 30 1000   0 440 StatusCode
91 DATE N         16         16 0/ 0    0   0   0 StatusTimestamp
12 VARCHAR Y        800        800 129/144 1000   0 440 InterfaceLog
Exiting hgodtab, rc=0 at 2014/09/22-13:35:08
Entered hgodafr, cursor id 0 at 2014/09/22-13:35:08
Free hoada @ 0000000005F58270
Exiting hgodafr, rc=0 at 2014/09/22-13:35:08
Entered hgotcis at 2014/09/22-13:35:08
Calling SQLStatistics for XXX_INTERFACE
IndexType=SQL_TABLE_STAT: cardinality=0
IndexType=1: PK_XXX_Interface
IndexType=3: IX_TableID
IndexType=3: IX_TableName
Calling SQLColumns for dbo.SQL_app_INTERFACE
#1 Column "InterfaceID": dtype=2, colsize=20, decdig=0, char_octet_length=0, cumulative avg row len=15
#2 Column "TableName": dtype=-9, colsize=30, decdig=0, char_octet_length=60, cumulative avg row len=60
#3 Column "TableID": dtype=4, colsize=10, decdig=0, char_octet_length=0, cumulative avg row len=64
#4 Column "StatusCode": dtype=-9, colsize=30, decdig=0, char_octet_length=60, cumulative avg row len=109
#5 Column "StatusTimestamp": dtype=93, colsize=23, decdig=3, char_octet_length=0, cumulative avg row len=125
#6 Column "InterfaceLog": dtype=-9, colsize=400, decdig=0, char_octet_length=800, cumulative avg row len=725
3 Index(es) found:
Index: PK_XXX_Interface, type=1, ASCENDING, UNIQUE, cardinality=0
#1 Column 1: InterfaceID
Index: IX_TableID, type=3, ASCENDING, NON-UNIQUE, cardinality=0
#1 Column 3: TableID
Index: IX_TableName, type=3, ASCENDING, NON-UNIQUE, cardinality=0
#1 Column 2: TableName
Exiting hgotcis, rc=0 at 2014/09/22-13:35:08

ORA-12704: character set mismatch odbc

Hi I have a query which is working find in most of the machines through ODBC connection. On one oracle server i am getting "ORA-12704: character set mismatch"
SELECT '' as Col1, Fname from CustTable
Where FPrefix = ''

user8971316 wrote:
Hi I have a query which is working find in most of the machines through ODBC connection. On one oracle server i am getting "ORA-12704: character set mismatch"
SELECT '' as Col1, Fname from CustTable
Where FPrefix = ''
bcm@bcm-laptop:~$ oerr ora 12704
12704, 00000, "character set mismatch"
// *Cause: One of the following:
//         - The string operands(other than an nlsparams argument) to an
//           operator or built-in function do not have the same character
//           set.
//         - An nlsparams operand is not in the database character set.
//         - String data with character set other than the database character
//           set is passed to a built-in function not expecting it.
//         - The second argument to CHR() or CSCONVERT() is not CHAR_CS or
//           NCHAR_CS.
//         - A string expression in the VALUES clause of an INSERT statement,
//           or the SET clause of an UPDATE statement, does not have the
//           same character set as the column into which the value would
//           be inserted.
//         - A value provided in a DEFAULT clause when creating a table does
//           not have the same character set as declared for the column.
//         - An argument to a PL/SQL function does not conform to the
//           character set requirements of the corresponding parameter.
// *Action:

[8i] ORA-12704: character set mismatch (and other issues)

I've been trying to put together sample data on this problem since Friday, but I'm having issues. I'm thinking the problem is something specific to the old database I'm trying to work in:
BANNER
Oracle8i Enterprise Edition Release 8.1.7.2.0 - Production
PL/SQL Release 8.1.7.2.0 - Production
CORE    8.1.7.0.0       Production
TNS for HPUX: Version 8.1.7.2.0 - Production
NLSRTL Version 3.4.1.0.0 - ProductionI tried copying over all the data into my test database:
BANNER
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Product
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - ProductionAnd, I can't duplicate the problem there. In fact, I ran my original query in my test database, using the db llink, the query ran just fine.
But, I tried to create some sample data anyway to try to get some help here, so, I created 3 tables in my test database as SELECT from the old database (via a db link).
One table was really the results of a query (with many sub-queries) that was working just fine in the old database. It was the 2nd highest level query that wasn't giving me any problems. (Below, in my query, subquery 'a' runs just fine in the test database also; it's only the top level query that gives me an error.)
The other two tables I created were just simple sub-sets of the original tables in the old database.
I ran my query in my test database against those tables, and again, it ran just fine. No character set mismatch error.
So, based on the tables from the old database, I created the following test tables:
TEST TABLE DEFINITIONS
CREATE TABLE     test_inv_1
(     cust_id          CHAR(10)
,     item_id          VARCHAR2(32) -- becomes 96 if I create as select
,     match_item_id     CHAR(10)
,     docdate          DATE
,     tot_amt          NUMBER(5)
INSERT INTO     test_inv_1
VALUES('C1000','I0001','I0001',TO_DATE('01/01/2011','mm/dd/yyyy'),1000);
INSERT INTO     test_inv_1
VALUES('C1000','I0002','I0002',TO_DATE('01/05/2011','mm/dd/yyyy'),1050);
INSERT INTO     test_inv_1
VALUES('C1000','MANUAL ADJUSTMENT','MANUAL ADJ',TO_DATE('01/01/2011','mm/dd/yyyy'),1000);
INSERT INTO     test_inv_1
VALUES('C1001','I0003','I0003',TO_DATE('01/01/2011','mm/dd/yyyy'),500);
INSERT INTO     test_inv_1
VALUES('C1001','OTHER ADJUSTMENT','OTHER ADJU',TO_DATE('01/01/2011','mm/dd/yyyy'),50);
INSERT INTO     test_inv_1
VALUES('C1001','M123','M123',TO_DATE('01/10/2011','mm/dd/yyyy'),150);
CREATE TABLE     test_btab_1
(     billing_id          CHAR(10)     NOT NULL -- becomes 30
,     payment_terms_cd     CHAR(3)                -- becomes 9
INSERT INTO     test_btab_1
VALUES ('I0001', '01');
INSERT INTO     test_btab_1
VALUES ('I0002', '01');
INSERT INTO     test_btab_1
VALUES ('I0003', '02');
INSERT INTO     test_btab_1
VALUES ('M123', 'COD');
INSERT INTO     test_btab_1
VALUES ('I0004', '01');
CREATE TABLE     test_tabm_1
(     record_type     CHAR(4)          NOT NULL     -- becomes 12
,     record_key     CHAR(10)     NOT NULL     -- becomes 30
,     numeric_1     NUMBER(15,5)
,     numeric_5     NUMBER(7)
,     numeric_6     NUMBER(7)
INSERT INTO     test_tabm_1
VALUES ('LOCA','A1234',NULL,NULL,NULL);
INSERT INTO     test_tabm_1
VALUES ('TERM','01',2,10,30);
INSERT INTO     test_tabm_1
VALUES ('TERM','02',0,0,45);
INSERT INTO     test_tabm_1
VALUES ('TERM','COD',0,0,30);Again, the first table, test_inv_1, is an example of the results of a query that was working just fine in the old database. (There are comments in the table definitions above--I'll explain those in a bit.)
Here is the query I ran against this data:
QUERY
SELECT     a.*
,     1 - (t.numeric_1/100)          AS amt_pst_disc
,     a.docdate + t.numeric_5 - 1     AS disc_end_date
,     a.docdate + t.numeric_6 - 1     AS duedate
FROM     (
     SELECT     ic.*
     ,     CASE
               WHEN     b.payment_terms_cd     IS NULL
               THEN     CAST('03' AS CHAR(10))
               ELSE     CAST(b.payment_terms_cd AS CHAR(10))
          END                         AS pay_term
     ,     CASE
               WHEN     b.payment_terms_cd     IS NULL
               THEN     'Default Payment Terms'
          END                         AS pt_flag
     FROM     test_inv_1 ic
     ,     test_btab_1 b
     WHERE     ic.match_item_id     = b.billing_id (+)
     ) a
,     test_tabm_1 t
WHERE     a.pay_term     = t.record_key
AND     t.record_type     = 'TERM'
;In the old database, I get the error:
WHERE   a.pay_term      = t.record_key
ERROR at line 107:   --this is actually line 22 in the above query, since test_inv_1 represents the results of a sub-query
ORA-12704: character set mismatchIn my test database, in every form, including with the sample data above, I don't have any problems.
I unfortunately don't have a v8 test environment, and I suspect there aren't many people who actually do, anymore, so using my v10 test database is the best I can do to come up with test data...
The other odd thing I noticed is that when I DESC the tables I created in my test database via SELECT statements, and compare them with the tables I created from CREATE statements (based on the table descriptions I got from the old database), some of the data lengths don't match up. That's what's in the comments in my table definitions. I noted where the tables I created via SELECT statements had different data lengths. I'm not sure if it's important or not, but in case it is, I thought I'd include it.
Also, I'm creating this query to make a report for someone else, and the reporting system only has access to the v8 database, not my test database. So, I'm stuck making the query run against it.
Any help on this would be greatly appreciated!

I think it has something to do with my CASE statement. I found a kind of work-around solution. Instead of getting payment_term_cd associated with the item_id, the person I'm creating the report for wants the payment terms associated with the cust_id. Now, btab has the one associated with item_id, and not every item_id is in the btab table, so in my query, I was assuming a default value of '03' when it didn't find a payment_term_cd (i.e. it was NULL) for an item_id, which is what my first CASE statement is doing.
However, every cust_id definitely has a payment_term_cd associated with it (in another table I did not provide sample data for, since I didn't know I'd need to use it). Here's the general idea of that table:
CREATE TABLE     test_cust_1
(     cust_id               CHAR(10)     NOT NULL
,     payment_terms_cd     CHAR(3)     --while it's not specified as NOT NULL, there are no NULLs for this column. I think anything that would be NULL, the system initializes as '***'
INSERT INTO     test_cust_1
VALUES ('C1000','01');
INSERT INTO     test_cust_1
VALUES ('C1001','03');
INSERT INTO     test_cust_1
VALUES ('C1002','COD');So, there's no need for me to do a case statement. I can get away with something like:
SELECT     ip.item_id
,     ip.docdate
,     ip.cust_id
,     ip.tot_amt
,     ip.pay_terms
,     t.record_key
FROM     (
     SELECT     i.item_id
     ,     i.docdate
     ,     i.cust_id
     ,     i.tot_amt
     ,     CAST(c.payment_terms_cd AS CHAR(10))     AS pay_terms
     FROM     test_inv_1 i
     ,     test_cust_1 c
     WHERE     c.cust_id     = i.cust_id
     AND     i.tot_amt     <> 0
     ) ip
,     test_tabm_1 t
WHERE     t.record_key     = ip.pay_terms
AND     t.record_type     = 'TERM'-- edited out the incorrect results
Anyway, when I used this new table with my original query in the 8i database, I didn't get a character set error, so that's why I think it has to do with the case statement.
Edited by: user11033437 on Aug 22, 2011 1:43 PM -- fixed an error in my results

How to fix ORA-12704: character set mismatch

I am newish to oracle and am trying to work out why the following doesn't work:
create table utest(test nvarchar2(100));
insert into utest values('fish');
select test from utest union select '' from utest;
I need to be able to do a union on a table with an nvarchar2 fields, where on union, some of the columns are simply ''.
Not quite sure how to work out which oracle version exactly this is, we are given remote access via JDBC.

Hi
i have a similar issue on a customer. unfortunatly i am not able to modify the commands because i am not the developer. but i see in the logfile, that a ORA-12703 - Character Set Missmatch Occours after a specifiec command. after some investigation i found the command:
SELECT * FROM (SELECT DISTINCT ATTACHMENTID, FTN.USERID, FTN.MSGID, FTN.TYPEFLD, DS.DOCSERVERID, DOCSERVERPATH, DSTYPE,DSENABLED, DA.DATAARCHIVEID,FILENAME, STARTINGPOS, COMPRESSEDSIZE, UNCOMPRESSEDSIZE, MSGDATEHIGH, MSGDATELOW, FLAGS, STORAGEMETHOD, SUBJECT, FROMFLD FROM CONTAINSATTACHMENT CA RIGHT JOIN FT_NOTIFY FTN ON CA.MSGID=FTN.MSGID , PROFILE P, PROFILELOCATION PL, DATAARCHIVE DA, DOCUMENTSERVER DS WHERE FTN.MSGID >= 547609 AND FTN.MSGID <= 557609 AND P.MSGID=PL.MSGID AND DS.DOCSERVERID=DA.DOCSERVERID AND DA.DATAARCHIVEID=PL.DATAARCHIVEID AND FTN.MSGID=P.MSGID AND FTN.SEARCH_INDEX_ID=2 AND TYPEFLD='A' UNION SELECT DISTINCT NULL AS ATTACHMENTID, FTN.USERID, FTN.MSGID, FTN.TYPEFLD,0 AS DOCSERVERID,'' AS DOCSERVERPATH,0 AS DSTYPE,0 AS DSENABLED,0 AS DATAARCHIVEID,'' AS FILENAME,0 AS STARTINGPOS,0 AS COMPRESSEDSIZE,0 AS UNCOMPRESSEDSIZE,0 AS MSGDATEHIGH,0 AS MSGDATELOW,-1 AS FLAGS, 0 AS STORAGEMETHOD,'' AS SUBJECT, '' AS FROMFLD FROM FT_NOTIFY FTN WHERE FTN.MSGID >= 547609 AND FTN.MSGID <= 557609 AND FTN.SEARCH_INDEX_ID=2 AND TYPEFLD='R') ORDER BY MSGID
when i replace the "'' AS..." in the bottom of the script with the "cast( '' as nvarchar(255)) AS..." it works as expected. as i sayd, i cant change the code but we have the system working for ages and after we set up a new server, it stops working - so can it be possible that other versions of Oracle (Server or Client) support this without a cast? Or is there some "Special Setting" what can help here?
Thank you in advance
Martin

Character set mismatch in copying from oracle to oracle

I have a set of ODI scripts that are copying from a source JD Edwards ERP database (Oracle 10g) to a BI datamart (Oracle 10g) and all the original scripts work OK.
However I have mapped on to some additional tables in the ERP source database and some new BI tables in the target datamart database (oracle - to - oracle) but get an error when I try ro execute these.
The operator log shows that the error is in the 'INSERT FLOW INTO I$ TABLE' and the error is ORA-12704 character set mismatch.
The character set for both Oracle databases are the same (and have not changed) the main NLS_CHARACTERSET is AL332UTF8 and the national NLS_NCHAR_CHARACTERSET is AL16UTF16.
But this works for tables containing NCHAR and NUMBER in previous scripts but not for anything I write now.
The only other difference is that there was a recent upgrade of ODI to 10.1.3.5 - the repositories are also upgraded.
Any ideas ?

Hi Ravi,
yes, a gateway would help. In 11.2 Oracle offers 2 kind of gateways to a SQL Server - a gateway for free which is based on 3rd party ODBC drivers (you need to get them from a 3rd party vendor, they are not included in the package) and called Database Gateway for ODBC (=DG4ODBC) and a very powerful Database Gateway for MS SQL Server (=DG4MSQL) which allows you also to execute distributed transactions and call remote SQL Server stored procdures. Please keep in mind that DG4MSQL requires a separate license.
As you didn't post which platform you're going to use, please check out On "My Oracle Support" (=MOS) where you'll find notes how to configure each gateway for all supported platforms - just look for DG4MSQL or DG4ODBC
On OTN you'll find the also the manuals.
DG4ODBC: http://download.oracle.com/docs/cd/E11882_01/gateways.112/e12070.pdf
DG4MSQL: http://download.oracle.com/docs/cd/E11882_01/gateways.112/e12069.pdf
The generic gateway installation for Unix: http://download.oracle.com/docs/cd/E11882_01/gateways.112/e12013.pdf
and for Windows: http://download.oracle.com/docs/cd/E11882_01/gateways.112/e12061.pdf

Character set mismatch with UTF-8

I get character set mismatch error when attempting to run a JDBC PreparedStatement to query
a table with primary key column of type NCHAR
I'm using the thin 8i driver
I'm using setString() to set the bind the parameter value to the statement
Some of the documentation makes it sound like the driver will convert between character
sets automatically. Other parts make it look like I should use the setCHAR() method of
Oracle's OraclePreparedStatement class.
Is there an easy way to do this ?

I get character set mismatch error when attempting to run a JDBC PreparedStatement to query
a table with primary key column of type NCHAR
I'm using the thin 8i driver
I'm using setString() to set the bind the parameter value to the statement
Some of the documentation makes it sound like the driver will convert between character
sets automatically. Other parts make it look like I should use the setCHAR() method of
Oracle's OraclePreparedStatement class.
Is there an easy way to do this ?

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

Help:character set mismatch after DB installation

hai friends,
After my oracle installtion database character set *(AL32UTF8)* and client character
set*(WE8MSWIN1252)* became different..and a message specifies that i can set client character set through
HKLM/SOFTWARE/ORACLE/KEY_trial registry..so what i suposed to do..now the NLS_LAG.reg contains the value as AMERICAN_AMERICA.WE8MSWIN1252...so for changing from one character set to another what i have to type inside NLS_LAG.reg...
thanks in advance...

The client character set must match the Operating System code page, so check HKLM\SYSTEM\CurrentControlSet\Control\Nls\CodePage\, look for an entry with name ACP, if its value is "1252" then NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252 is OK. See Note *179133.1* The correct NLS_LANG in a Windows Environment for more information.
HTH
Enrique

ORA-24812: character set conversion to or from UCS2 failed

Oracle 9.2.0.4
PHP 4.3.3
data in db is in unicode UTF8
NLS_LANG=AMERICAN_AMERICA.AL32UTF8
Then reading more than N Kb from CLOB I get ORA-24812.
If clob less than N Kb it's working fine.
On 9.2.0.1 SELECT convert(myclob, 'UTF16','AL32UTF8') causing instance crash.
Can you help me ?

What PHP DB interface are you using (oci8 calls, PEAR
DB etc)?OCI8
>
How big is "N kb"? Is it always this size?I don't know ... in CLOB I store serialized php array (report), where are problem only on one realy big report.
>
What does "instance crash" mean? The whole DB
instance,
the Oracle shadow process, or the PHP session?Whole instance, but in 9.2.0.4 it fixed.

Character set Mismatch

Hi,
I'm trying to update an NCLOB field with a plain text file (Word ML format). I know that I have to convert the text to NCLOB using the to_NCLOB function. But, the function requires an argument, it doesn't take a file. What else can I use to convert A FILE to NLCOB???
Thanks in advance,
Marc.

Remember that an external file is not a database object and then it can't be referenced by other database objects.
Anyway to receive an answer it would be helpful if you say:
- What is your environment (oracle forms, a web application, a client-server application you're developing or ...what else).
- Where the file is stored (in the host of the RDBMS, in the client machine or somewhere else ).
Bye Alessandro

Character set error comming in stored procedure

i am writing these SQL lines when execute these giving me error
SQL Lines
SELECT DocDate,
NVL(SMTransType.Description, '<Not Provided>') DESCRIPTION,
CASE
WHEN DocType = 'GRN' THEN ( SELECT GrnNo
FROM IVGrnMst
WHERE ID = DocID )
END "ReceiptNo",
CASE
WHEN DocType = 'PUR' THEN ( SELECT PrNo ---- its data type VARCHAR2(50)
FROM IVPurReturnMst
WHERE ID = DocID )
WHEN DocType = 'SCP' THEN ( SELECT ConsumptionCode --its data type NVARCHAR2(50)*
FROM IvStoreConsumptionMst
WHERE ConsumptionId = DocID )
END "IssueNo"
FROM IVStockRegister Stock INNER JOIN
SMTransType
ON Stock.DocType = SMTransType.Code;
SQL SQL Error: ORA-12704: character set mismatch
12704. 00000 - "character set mismatch"

are you sure your SELECTs on in the case after when return single value?
try this, please
SELECT DocDate,
NVL(SMTransType.Description, '<Not Provided>') DESCRIPTION,
CASE
    WHEN DocType = 'GRN'
    THEN
      ( SELECT MIN(GrnNo) FROM IVGrnMst WHERE ID = DocID
END "ReceiptNo",
CASE
    WHEN DocType = 'PUR'
    THEN
      (SELECT MIN(PrNo) ---- its data type VARCHAR2(50)
      FROM IVPurReturnMst
      WHERE ID = DocID
    WHEN DocType = 'SCP'
    THEN
      (SELECT MIN(ConsumptionCode) --its data type NVARCHAR2(50)
      FROM IvStoreConsumptionMst
      WHERE ConsumptionId = DocID
END "IssueNo"
FROM IVStockRegister Stock
INNER JOIN SMTransType
ON Stock.DocType = SMTransType.Code;

EF6 with ODP 12cR3 : ORA-12704 (VARCHAR2 not supported?)

         Hi!
          We cannot port our working code from EF5 to EF 6.1.2, because the generated SQL output unicode query which is not compatible with VARCHAR2 column.
          How can we fix this issue ?
            Our Setup
             Oracle 11.2.0.3.0
             NLS_CHARACTERSET               WE8MSWIN1252
             NLS_NCHAR_CHARACTERSET         AL16UTF16
                -- TEST
                  CREATE TABLE "TEST"
                   ( "ID" NUMBER(*,0) NOT NULL ENABLE,
                 "NAME" VARCHAR2(20),
                 "VALUE" VARCHAR2(20)
                   ) PCTFREE 10 INITRANS 1 NOCOMPRESS LOGGING
                  STORAGE( INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
                -- ID
                ALTER TABLE "TEST" ADD CONSTRAINT "ID" PRIMARY KEY ("ID") ENABLE;
             Objective : Trying to port working code from EF5 to EF6.1.2
             Problem : Generated SQL contains unicode query when using VARCHAR2 column type.
            using (var ctx = new Entities())
                var queryable = ctx.TESTs.Where(x => x.NAME.Contains("test")).Select(
                    t => new
                        TestVarcharVsUnicode = t.VALUE + "AnotherStringLiteralWillGenerateNvarcharSQL"
                /* Generated SQL
                queryable =
                    SELECT
                    1 AS "C1",
                    ((CASE WHEN ("Extent1"."VALUE" IS NULL) THEN N'' ELSE "Extent1"."VALUE" END)||('AnotherStringLiteralWillGenerateNvarcharSQL')) AS "C2"
                    FROM "TES_RA"."TEST" "Extent1"
                    WHERE ("Extent1"."NAME" LIKE '%test%')
                var result = queryable.ToList();   // ORA-12704: character set mismatch here because VALUE column type is VARCHAR2 not NVARCHAR2
UPDATE: By using an IDbCommandInterceptor class we can replace those Unicode string before execution. But it's only a workaround until we found the correct way to fix it.
Thank you in advance,
Jean Francoeur

Hi Verolamaz,
No update on our side.
We've also tried modelBuilder.Properties<string>().Configure(c => c.HasColumnType("varchar2"));
But the generated SQL stay the same...
Jean

NLS CHARACTER SET 변경 방법 (ORACLE 7)

제품 : ORACLE SERVER
작성날짜 : 2004-11-09
NLS CHARACTER SET 변경 방법 (ORACLE 7)
======================================
PURPOSE
이 자료는 Oracle RDBMS SERVER에서 NLS CHARACTER SET 변경 방법에 대한
내용을 소개한다.
[ ORACLE 7 에서만 가능 ]
데이타베이스의 CHARACTER SET은 데이타 딕셔너리 테이블인 sys.props$에
들어 있다.
SQL>desc sys.props$
Name Null? Type
NAME NOT NULL VARCHAR2(30)
VALUE$ VARCHAR2(2000)
COMMENT$ VARCHAR2(2000)
SQL>column c1 format a30
SQL>select name c1, value$ c1 from sys.props$;
C1 C1
DICT.BASE 2
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_DATE_FORMAT DD-MON-YY
NLS_DATE_LANGUAGE AMERICAN
NLS_CHARACTERSET US7ASCII
NLS_SORT BINARY
GLOBAL_DB_NAME NLSV7.WORLD
여기서 NLS_CHARACTERSET에 현재 DB의 CHARACTER SET이 들어 있는데
이 값을 변경하여 DB의 CHARACTER SET을 변경할 수 있다.
여기서는 US7ASCII에서 KO16KSC5601로 옮기는 경우를 알아보자.
우선 바꾸고자 하는 CHRACTER SET이 지원되는 지를 다음 명령으로
확인한다.
select convert('a','KO16KSC5601','US7ASCII') from dual;
만약 이 Select 문에서 ORA-01482 에러가 발생하면 지정한 CHARACTER
SET이 지원되지 않는 경우이며 에러가 발생하지 않으면 CHARACTER
SET을 변경할 수 있다.
작업을 하기 전에는 만약을 위해서 DB 전체를 백업 받아두도록 한다.
CHARACTER SET 을 잘못 변경하면 DB 를 OPEN 할 수가 없기 때문이다.
1. 다음의 Update문을 실행하여 CHARACTER SET을 변경한다.
UPDATE sys.props$
SET value$ = 'KO16KSC5601'
WHERE name = 'NLS_CHARACTERSET';
Update 시에 NLS_CHARACTERSET을 지원되지 않는 값으로 잘못 설정하거나
실수로 콘트롤 문자 같은 것이 들어가게 되면 DB가 Shutdown 된 다음에는
Startup 이 안되므로 Update 후에 다음 명령으로 확인을 한 다음에
Commit을 하도록 한다.
select name, value$
from sys.props$
where value$ = 'KO16KSC5601';
Select가 제대로 출력되면 Commit 하고 Shutdown 했다가 Startup 하게
되면 새로운 CHARACTER SET 값을 갖게 된다. SELECT가 안 되면 ROLLBACK
하고 UPDATE부터 다시 하도록 한다.
2. 환경 변수 NLS_LANG 을 변경한다.
.profile 에서
NLS_LANG=American_America.KO16KSC5601; export NLS_LANG
또는 .cshrc 에서.
setenv NLS_LANG American_America.KO16KSC5601
*** win95 및 winnt의 client에서는 registry editor에서 NLS_LANG 값을
맞추어준다.
주의 !!!
: 위의 작업을 하기 전에 발생할 가능성이 있는 문제점
1) update 중 KO16KSC5601 이나 US7ASCII 등에서 철자를 잘못 입력하시면,
db 재기동 후에, 다음과 같은 에러가 발생합니다.
ora-12708
12708, 00000, "error while loading create database NLS parameter %s"
2) KO16KSC5601과 US7ASCII의 비교
Character set : KO16KSC5601 인 경우
===================================
: double byte encoding schema 이므로, 한글의 경우 2 bytes 를 크기 1로
계산하는 함수들이 있습니다.
그리고, table , column name에 한글을 double quote 없이 사용할 수 있습니다.
예)
SQL> create table 시험1
2 (컬럼1 varchar(10));
가
a
홍길동
SQL> select length(컬럼1) from 시험1;
1
1
3
SQL> select lengthb(컬럼1) from 시험1;
2
1
6
Character set : US7ASCII 인 경우
=================================
: single byte 7 bit encoding 을 사용합니다.
한글로 된 table, column 이름 사용 시 double quote를 반드시 사용해야 한다.
예)
SQL> create table "사원"
2 ("사원이름" varchar2(10));
가
a
홍길동
SQL> select length("사원이름") from "사원";
2
1
6
SQL> select lengthb("사원이름") from "사원";
2
1
6
US7ASCII일 때에는 vsize, lengthb function의 결과가 length 함수와 모두
동일합니다.
cf) substr, substrb 함수도 위의 length, lengthb의 관계와 같음.

제품 : ORACLE SERVER
작성날짜 : 2004-11-09
NLS CHARACTER SET 변경 방법 (ORACLE 7)
======================================
PURPOSE
이 자료는 Oracle RDBMS SERVER에서 NLS CHARACTER SET 변경 방법에 대한
내용을 소개한다.
[ ORACLE 7 에서만 가능 ]
데이타베이스의 CHARACTER SET은 데이타 딕셔너리 테이블인 sys.props$에
들어 있다.
SQL>desc sys.props$
Name Null? Type
NAME NOT NULL VARCHAR2(30)
VALUE$ VARCHAR2(2000)
COMMENT$ VARCHAR2(2000)
SQL>column c1 format a30
SQL>select name c1, value$ c1 from sys.props$;
C1 C1
DICT.BASE 2
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_DATE_FORMAT DD-MON-YY
NLS_DATE_LANGUAGE AMERICAN
NLS_CHARACTERSET US7ASCII
NLS_SORT BINARY
GLOBAL_DB_NAME NLSV7.WORLD
여기서 NLS_CHARACTERSET에 현재 DB의 CHARACTER SET이 들어 있는데
이 값을 변경하여 DB의 CHARACTER SET을 변경할 수 있다.
여기서는 US7ASCII에서 KO16KSC5601로 옮기는 경우를 알아보자.
우선 바꾸고자 하는 CHRACTER SET이 지원되는 지를 다음 명령으로
확인한다.
select convert('a','KO16KSC5601','US7ASCII') from dual;
만약 이 Select 문에서 ORA-01482 에러가 발생하면 지정한 CHARACTER
SET이 지원되지 않는 경우이며 에러가 발생하지 않으면 CHARACTER
SET을 변경할 수 있다.
작업을 하기 전에는 만약을 위해서 DB 전체를 백업 받아두도록 한다.
CHARACTER SET 을 잘못 변경하면 DB 를 OPEN 할 수가 없기 때문이다.
1. 다음의 Update문을 실행하여 CHARACTER SET을 변경한다.
UPDATE sys.props$
SET value$ = 'KO16KSC5601'
WHERE name = 'NLS_CHARACTERSET';
Update 시에 NLS_CHARACTERSET을 지원되지 않는 값으로 잘못 설정하거나
실수로 콘트롤 문자 같은 것이 들어가게 되면 DB가 Shutdown 된 다음에는
Startup 이 안되므로 Update 후에 다음 명령으로 확인을 한 다음에
Commit을 하도록 한다.
select name, value$
from sys.props$
where value$ = 'KO16KSC5601';
Select가 제대로 출력되면 Commit 하고 Shutdown 했다가 Startup 하게
되면 새로운 CHARACTER SET 값을 갖게 된다. SELECT가 안 되면 ROLLBACK
하고 UPDATE부터 다시 하도록 한다.
2. 환경 변수 NLS_LANG 을 변경한다.
.profile 에서
NLS_LANG=American_America.KO16KSC5601; export NLS_LANG
또는 .cshrc 에서.
setenv NLS_LANG American_America.KO16KSC5601
*** win95 및 winnt의 client에서는 registry editor에서 NLS_LANG 값을
맞추어준다.
주의 !!!
: 위의 작업을 하기 전에 발생할 가능성이 있는 문제점
1) update 중 KO16KSC5601 이나 US7ASCII 등에서 철자를 잘못 입력하시면,
db 재기동 후에, 다음과 같은 에러가 발생합니다.
ora-12708
12708, 00000, "error while loading create database NLS parameter %s"
2) KO16KSC5601과 US7ASCII의 비교
Character set : KO16KSC5601 인 경우
===================================
: double byte encoding schema 이므로, 한글의 경우 2 bytes 를 크기 1로
계산하는 함수들이 있습니다.
그리고, table , column name에 한글을 double quote 없이 사용할 수 있습니다.
예)
SQL> create table 시험1
2 (컬럼1 varchar(10));
가
a
홍길동
SQL> select length(컬럼1) from 시험1;
1
1
3
SQL> select lengthb(컬럼1) from 시험1;
2
1
6
Character set : US7ASCII 인 경우
=================================
: single byte 7 bit encoding 을 사용합니다.
한글로 된 table, column 이름 사용 시 double quote를 반드시 사용해야 한다.
예)
SQL> create table "사원"
2 ("사원이름" varchar2(10));
가
a
홍길동
SQL> select length("사원이름") from "사원";
2
1
6
SQL> select lengthb("사원이름") from "사원";
2
1
6
US7ASCII일 때에는 vsize, lengthb function의 결과가 length 함수와 모두
동일합니다.
cf) substr, substrb 함수도 위의 length, lengthb의 관계와 같음.

Insert Chinese Data(Character Set

Can any Chinese DBA tell me how to store chinese data in Oracle 8.1.5.0.0 Database.
I tried the combination of UTF8 database character set with UTF8 national character set and UTF8 database character set with ZHS16MACCGB231280 national character set. A column in a table was defined as nchar/nvarchar2. But when I tried to insert chinese data into the column using insert into... command, I always got the error message 'Character Set Mismatch'.

Originally NCHAR was defined for a few selective fixed with Aisan character sets. In 9i it was redefined to support unicode. For 8.1.5 you will need to store your Chinese data in char, varchar, and CLOB data types.

Ora-12704: character set mismatch

Similar Messages

Maybe you are looking for