NLS_LENGHT_SEMANTICS

Hi,
I have a requirement that the database must be having CHAR instead of BYTE as its semantics because during migration it is causing issues.
When i check the database using,
SQL> show parameter nls_LENGTH_SEMANTICS;
NAME
TYPE VALUE
nls_length_semantics
string CHAR
So it says that the CHAR is the nls_length_semantics. But if i use,
SQL> SELECT * FROM NLS_DATABASE_PARAMETERS;
PARAMETER
VALUE
NLS_LANGUAGE
AMERICAN
NLS_NCHAR_CHARACTERSET
AL16UTF16
NLS_TERRITORY
AMERICA
PARAMETER
VALUE
NLS_CURRENCY
$
NLS_ISO_CURRENCY
AMERICA
NLS_NUMERIC_CHARACTERS
PARAMETER
VALUE
NLS_CHARACTERSET
AL32UTF8
NLS_CALENDAR
GREGORIAN
NLS_DATE_FORMAT
DD-MON-RR
PARAMETER
VALUE
NLS_DATE_LANGUAGE
AMERICAN
NLS_SORT
BINARY
NLS_TIME_FORMAT
HH.MI.SSXFF AM
PARAMETER
VALUE
NLS_TIMESTAMP_FORMAT
DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT
HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT
DD-MON-RR HH.MI.SSXFF AM TZR
PARAMETER
VALUE
NLS_DUAL_CURRENCY
$
NLS_COMP
BINARY
NLS_LENGTH_SEMANTICS
BYTE
PARAMETER
VALUE
NLS_NCHAR_CONV_EXCP
FALSE
NLS_RDBMS_VERSION
10.2.0.3.0
it says that NLS_LENGTH_SEMANTICS is BYTE.
Can anyone let me know what is the exact LENGTH_SEMANTICS in the database. It is confusing. Am i missing/going wrong somewhere?
If it is byte, can i change to CHAR and later back to BYTE.
Please help.

Hello,
Can anyone let me know what is the exact LENGTH_SEMANTICS in the database. It is confusing.To go short, if you have NLS_LENGTH_SEMANTICS to BYTE (this is the default) it means that when you define a Column Datatype to, for instance, VARCHAR2(100), you can store in this field a value up to 100 Bytes length.
With Western Character Set (WE8ISO... or US7ASCII) 1 Character = 1 Byte, so in these languages, 100 bytes let you store 100 characters.
But, when you use other languages (for instance Chinese) you have to use multi-bytes Character Set. Unicode AL32UTF8 is often used.
In Unicode 1 Character may need up to 4 Bytes to be stored.
So 100 bytes doesn't mean that you can store 100 characters.
If it is byte, can i change to CHAR and later back to BYTE
To manage this you have 2 solutions:
- 1. set the CHAR Option at the column datatype definition level --> VARCHAR2(100 CHAR)
- 2. set the parameter NLS_LENGTH_SEMANTICS to CHAR.
The second solution will affect all the database and will be effective after the instance restart (even if this parameter is dynamic).
I advise you to read the following Note [ *ID 144808.1* ] from My Oracle support:
Examples and limits of BYTE and CHAR semantics usage (NLS_LENGTH_SEMANTICS)+
Hope this help.
Best regards,
Jean-Valentin

Similar Messages

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

Storing Foreign Characters in oracle 9i Lite Client Database.

Hi All,
My Database configuration Is
RDBMS VERSION 9.0.1.1.1
NLS_CHARACTERSET AL32UTF8
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
Operating System Windows 2000
My Oracle Lite configuration Is
Oracle9i Lite Release 5.0.2.0.8
Client Locations:
Africa,Europe,Asia,America
Currently all clients store data only in English in the client odb either through java and oracle forms applications.
We want to now store data for some specific tables, in the clients own language.Also we should be able to retrieve that data and see that data as it was entered.
For example :
The client in china after downloading the odb should be able to enter the data for that specific tables in the Chinese language.(They use windows 2000/XP English version).
1. What are the settings i need to do in the client environment?
like installing Chinese font or setting NLS_LANG parameter etc...
2. What are the settings i need to do in the server environment?
Because there should not be any loss of any data or junk values getting stored instead of actual values entered by clients.
Also when i query that specific tables in the oracle database after synchronization i should be able to view that data entered by the clients in their own language.
Eg:data entered by china clients should be visible in chinese fonts,
data entered by brazil clients should be visible in brazilian fonts,
data entered by vietnam clients should be visible in vietnamese fonts.
3. will there be any synchronization issues when clients try to sync after data entry with
their own languages?
Please do advice on these issue...........

I have given you the info of how to set up Oracle Lite for UTF8. I can only point you in the direction for globalization on the enterprise server. Also note that Oracle Lite only support NLS_LENGHT_SEMANTICS=BYTE, your EE database will be CHAR, so you have to alter the session paramter before you create the repository and/or publish your application.
Here is a Oracle Document on Globalization:
http://www.oracle.com/technology/tech/globalization/pdf/TWP_AppDev_Unicode_10gR2.pdf
Here is what Oracle Lite's Developers Guide has on development of linguistic sorts:
2.11 Support for Linguistic Sort
Linguistic sort is a feature for the ASCII version of Oracle Database Lite. It produces culturally acceptable order of strings for a specified language or collation sequence. The ASCII version supports several code pages defined by single-byte 8-bit encoding schemes. Each of these code pages is a super set of 7-bit ASCII, and the additional accented characters necessary to support a group of European languages are included in the upper 128 bytes. A new string comparison mechanism is provided that produces strings in a linguistically correct order by mapping each collation element of a string to the corresponding 8-bit value of the supported code page.
2.11.1 Creating Linguistic Sort Enabled Databases
The linguistic sort capability must be enabled when the database is created using the CREATEDB command line utility with the <collation_sequence> enabled.
Note:
For more information on the CREATEDB utility, see Section A.2, "CREATEDB".
The behavior of the ORDER_BY clause and the WHERE condition are determined by how the NLS_SORT parameter is implemented. Binary sorting is the default setting, and is used unless the <collation_sequence> parameter is set to use the linguistic sort ordering rules.
NLSRT is not supported in the current version of Oracle Database Lite. Therefore, NCHAR data type is not yet available.
2.11.2 How Collation Works
Collation refers to ordering of strings into a culturally acceptable sequence. A collation sequence is a sequence of all collation elements from an alphabet from smallest collation order to the largest. Once a collation sequence is given, orders of all strings from the same alphabet are fixed. As such, the collation sequence encodes the linguistic requirements on collation. A collation element is the smallest sub-string that can be used by the comparison function to determine the order of two strings.
2.11.3 Collation Element Examples
Normally, a collation element is just one character. In binary sorting, only one property, the code value that represents a character, is used. But in linguistic sorting, usually three properties. The primary level of difference is the base character. The secondary level of difference is for diacritical marks on a given base character. The tertiary level of difference is for the case of a given character. Punctuation can function as a fourth level of difference, but comparisons for punctuation occur last and are made at the binary rather than the linguistic level. These are used for each collation element. The following sections contain examples that demonstrate sorting priorities.
2.11.3.1 Sorting Normal Characters
This section lists a set of examples that describe how to sort normal characters.
Example 1
'a' < 'b'. There is a primary difference between them on the character level.
Example 2
'À' > 'a'. This difference occurs on the secondary level. Note that 'À'and 'a' are considered "equal" on the primary level.
Example 3
'À' < 'à' in FRENCH but 'À' > 'à' in GERMAN. This difference on the tertiary level. Note that 'À' and 'à' are considered being "equal" on the primary and secondary level. Also note that the case convention may be different for different language.
Example 4
'às' < 'at'. This is a difference on the primary level. This example shows the role of difference levels: the lower level differences are ignored if there is a primary level difference anywhere in the strings.
Example 5
'+data' < '-data' <'data' <'data-'. If strings are compared and present no difference on the primary, secondary, or tertiary levels, they are compared for punctuation.
2.11.3.2 Reverse Sorting of French Accents
Some languages, particularly French, require words to be ordered on the secondary level according to the last accent difference. This behavior is known as French secondary sorting or French accent ordering.
Example
'côte' < 'coté' in FRENCH but 'coté' < 'côte' in GERMAN. Note that the secondary difference of 'e' and 'é' occurred later than those of 'ô' and 'o'.
2.11.3.3 Sorting Contracting Characters
There are some special cases where two or more characters in a group can function as a single collation element. These types of collation elements are called 'contracting characters' or 'group characters'. In these cases each of these characters properties are assigned appropriate values.
Example
'h' < 'ch' < 'i' in XCZECH. Here 'ch' is assigned a primary property value which differentiates it from 'h' and 'i', such that 'h' < 'ch' < 'i'. Note that 'ch' is treated as a single character.
2.11.3.4 Sorting Expanding Characters
If a letter sorts as if it were a sequence of more than one letter, it is called an 'expanding character'. For example, in German the sharp s (ß) is treated as if it were a string of two characters 'ss' when comparing with other letters.
2.11.3.5 Sorting Numeric Characters
Only sorting of single digit characters from '0' to '9' is currently supported. For the supported European languages a digit character is always sorted as greater than any alphabetic character. For other languages this may be not the same. Other numeric characters such as Roman numeric characters and counting sequences, such as "one", "two", "three", are not supported at this time.
Example
'1' > 'z' in any European language, '1' < 'a' in LATVIAN. Note that this difference occurs on the primary level.

Websheet objects never valid

Trying to install websheet objects.
objects install no errors
run Validate websheet objects
get the following:
APEX$_ACL     Yes     Invalid     Valid     Valid     Valid
APEX$_WS_FILES     Yes     Invalid     Valid     Valid     Valid
APEX$_WS_HISTORY     Yes     Invalid     Valid     -     -
APEX$_WS_LINKS     Yes     Invalid     Valid     Valid     Valid
APEX$_WS_NOTES     Yes     Invalid     Valid     Valid     Valid
APEX$_WS_ROWS     Yes     Invalid     Valid     Valid     Valid
APEX$_WS_TAGS     Yes     Invalid     Valid     Valid     Valid
APEX$_WS_WEBPG_SECTIONS     Yes     Invalid     Valid     Valid     Valid
APEX$_WS_WEBPG_SECTION_HISTORY     Yes     Invalid     Valid     -     -
run correct invalid objects and get
alter table APEX$_WS_WEBPG_SECTION_HISTORY drop column application_user_id;
alter table APEX$_ACL drop column username;
alter table APEX$_ACL drop column priv;
alter table APEX$_ACL drop column created_by;
alter table APEX$_ACL drop column updated_by;
alter table APEX$_WS_WEBPG_SECTIONS drop column section_type;
alter table APEX$_WS_WEBPG_SECTIONS drop column nav_include_link;
alter table APEX$_WS_WEBPG_SECTIONS drop column chart_type;
alter table APEX$_WS_WEBPG_SECTIONS drop column chart_3d;
alter table APEX$_WS_WEBPG_SECTIONS drop column chart_label;
alter table APEX$_WS_WEBPG_SECTIONS drop column label_axis_title;
alter table APEX$_WS_WEBPG_SECTIONS drop column chart_value;
alter table APEX$_WS_WEBPG_SECTIONS drop column value_axis_title;
alter table APEX$_WS_WEBPG_SECTIONS drop column chart_aggregate;
alter table APEX$_WS_WEBPG_SECTIONS drop column chart_sorting;
alter table APEX$_WS_WEBPG_SECTIONS drop column created_by;
alter table APEX$_WS_WEBPG_SECTIONS drop column updated_by;
alter table APEX$_WS_ROWS drop column unique_value;
alter table APEX$_WS_ROWS drop column owner;
alter table APEX$_WS_ROWS drop column geocode;
alter table APEX$_WS_ROWS drop column created_by;
alter table APEX$_WS_ROWS drop column updated_by;
alter table APEX$_WS_HISTORY drop column column_name;
alter table APEX$_WS_HISTORY drop column application_user_id;
alter table APEX$_WS_NOTES drop column component_level;
alter table APEX$_WS_NOTES drop column created_by;
alter table APEX$_WS_NOTES drop column updated_by;
alter table APEX$_WS_LINKS drop column component_level;
alter table APEX$_WS_LINKS drop column show_on_homepage;
alter table APEX$_WS_LINKS drop column link_name;
alter table APEX$_WS_LINKS drop column created_by;
alter table APEX$_WS_LINKS drop column updated_by;
alter table APEX$_WS_TAGS drop column component_level;
alter table APEX$_WS_TAGS drop column created_by;
alter table APEX$_WS_TAGS drop column updated_by;
alter table APEX$_WS_FILES drop column component_level;
alter table APEX$_WS_FILES drop column name;
alter table APEX$_WS_FILES drop column mime_type;
alter table APEX$_WS_FILES drop column content_charset;
alter table APEX$_WS_FILES drop column content_filename;
alter table APEX$_WS_FILES drop column created_by;
alter table APEX$_WS_FILES drop column updated_by;
alter table APEX$_WS_FILES drop column image_alias;
alter table APEX$_WS_FILES drop column image_attributes;
click on correct
objects are still invalid
any ideas?
Thanks in advance.
Wayne
Edited by: wcoleku on Jun 30, 2010 2:44 PM
Additional info
It appears that we have 2 tables with the same name for the websheet objects example below
APEX_APPS is the schema owner. Could this be causing my problem?
OWNER OBJECT_TYPE OBJECT_NAME
APEX_APPS TABLE APEX$_ACL
APEX_040000 TABLE APEX$_ACL
APEX_APPS TABLE APEX$_WS_FILES
APEX_040000 TABLE APEX$_WS_FILES

Hi Wayne!
How i understand websheet objects validating procedure compare structure tables in original scheme apex_040000 and scheme owner.
So what we can see:
desc apex_040000.apex$_acl;
Имя Пусто? Тип
ID NOT NULL NUMBER
WS_APP_ID NOT NULL NUMBER
USERNAME NOT NULL VARCHAR2(255)
PRIV NOT NULL VARCHAR2(1)
CREATED_ON NOT NULL DATE
CREATED_BY NOT NULL VARCHAR2(255)
UPDATED_ON DATE
UPDATED_BY VARCHAR2(255)
desc apex_apps.apex$_acl;
Имя Пусто? Тип
ID NOT NULL NUMBER
WS_APP_ID NOT NULL NUMBER
USERNAME NOT NULL VARCHAR2(255 CHAR)
PRIV NOT NULL VARCHAR2(1 CHAR)
CREATED_ON NOT NULL DATE
CREATED_BY NOT NULL VARCHAR2(255 CHAR)
UPDATED_ON DATE
UPDATED_BY VARCHAR2(255 CHAR)
Username in original apex scheme VARCHAR2(255) and in the owner scheme VARCHAR2(255 CHAR).
Next,
show parameter NLS_LENGTH_SEMANTICS
NAME TYPE
VALUE
nls_length_semantics string
CHAR
How i understand problem with nls_lenght_semantics parameter....
Some workaround solutions:
1) Manual modify table columns such as:
alter apex_apps.apex$_acl modify username varchar2(255 byte);
alter apex_apps.apex$_acl modify PRIV VARCHAR2(1 byte);
After that run validate websheet again and you will see that the columns of the table were correct and you can create websheet applications.
2) ALTER SYSTEM set NLS_LENGTH_SEMANTICS = BYTE scope spfile; (I'm not sure that this is a good solution)
Restart Database, Remove Websheet database objects and create again.
Best regards, Igor.

Error 12899 when importing a dmp (PLEASE SOMEONE HELP ME)

Does anyone in this wolrd knows how to solve this problem. I have tried the alter system nls_lenght_semantics statement, it did not change the database parameter. I don't believe that that it's impossible to import a 9i dmp into a 10xe database. I need to know how I can fix this problem. please anyone could help me.

Hi there,
There is nothing wrong with NLS_LENGTH_SEMANTICS. It is BYTE by default. Swithing to CHAR will solve the problem with column size.
I made the database structure on OracleXE Beta, which is BYTE. Then I changed NLS_LENGTH_SEMANTICS to CHAR and "impdp"(WE to CL8MSWIN1251 using Univ.)
1. If you have problem with characterset try to "impdp" into OracleXE Universal. I think it will accept almost any charset.
2. There was an issue using NLS_CHARSET in environmental variable on PC Win.
3. Go to the Installation Guide and check NLS_CHARSET
4. Check SQL*Loader
Konstantin
Message was edited by:
konstantin.gudjev

NLS_LENGHT_SEMANTICS

Similar Messages

Maybe you are looking for