Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

500
CHAPTER 12 ■ DATATYPES
ops$tkyte@O10GUTF> select *
2 from nls_database_parameters
3 where parameter = 'NLS_CHARACTERSET';
PARAMETER
VALUE
------------------------------ --------------------
NLS_CHARACTERSET
AL32UTF8
ops$tkyte@O10GUTF> create table t
2 ( a varchar2(1),
3 b varchar2(1 char),
4 c varchar2(4000 char)
5 )
6 /
Table created.
Now, if we try to insert into our table a single character that is 2 bytes long in UTF, we
observe the following:
ops$tkyte@O10GUTF> insert into t (a) values (unistr('\00d6'));
insert into t (a) values (unistr('\00d6'))
*
ERROR at line 1:
ORA-12899: value too large for column "OPS$TKYTE"."T"."A"
(actual: 2, maximum: 1)
This example demonstrates two things:
• VARCHAR2(1) is in bytes, not characters. We have single Unicode character, but it won’t fit
into a single byte.
• As you migrate an application from a single-byte, fixed-width character set to a multibyte
character set, you might find that the text that used to fit into your fields no longer
does.
The reason for the second point is that a 20-character string in a single-byte character set
is 20 bytes long and will absolutely fit in a VARCHAR2(20). However a 20-character field could
be as long as 80 bytes in a multibyte character set, and 20 Unicode characters may well not
fit in 20 bytes. You might consider modifying your DDL to be VARCHAR2(20 CHAR) or using the
NLS_LENGTH_SEMANTICS session parameter mentioned previously when running your DDL to
create your tables.
If we insert that single character into a field set up to hold a single character, we will
observe the following:
ops$tkyte@O10GUTF> insert into t (b) values (unistr('\00d6'));
1 row created.
ops$tkyte@O10GUTF> select length(b), lengthb(b), dump(b) dump from t;
LENGTH(B) LENGTHB(B) DUMP
---------- ---------- --------------------
1 2 Typ=1 Len=2: 195,150