Skip to content

Unicode Considerations

If an IFS Cloud installation has requirements for handling more than two languages that exists in more than one character set or a language that normally uses double byte character set, you need to run your database with an Unicode database character set. Below follows Unicode considerations that are important for the Storage Tier.

Note: Double byte character sets is no longer supported in IFS Cloud, instead you should use an Unicode character set.

Database Character Set

Database character set determines which characters that are possible to store in an database. In an Unicode database character set should be set to AL32UTF8.

Character set Unicode support
AL32UTF8 Currently supporting Unicode 6.2
One character requires between 1 and 6 bytes in space when stored in the database.

To determine which database character set that is used on a database use this query in SQLPlus or similar tool:

SELECT *                               
 FROM nls_database_parameters           
 WHERE parameter = 'NLS_CHARACTERSET';

National character set

Could be set to any valid national character set, since IFS Cloud don’t use national character set data types.

The column width problem

A column within a table in an IFS Cloud database that should hold characters is using Oracle data type

VARCHAR2. When creating such column one has to specify the width of that column. This is done by entering the width between the brackets e.g. VARCHAR2(30). The problem is that in Oracle releases before Oracle9i this means that you can store 30 bytes, not characters, in that particular column. If for instance using the UTF8 character set in the database, which is a variable length character set, and only storing characters represented as three bytes (e.g. most Japanese signs) we only can store 10 characters which are represented as 30 bytes in the database.

In an Oracle10g database one can set the database to define VARCHAR2(30) as characters. This means that you always can store 30 characters in this column regarding of it's representation in bytes. The NLS_LENGTH_SEMANTICS initialization parameter should be set appropriately to in Init.ora, then all columns created uses the char semantics set in Init.ora. What really happens is that, when using an Unicode character set and NLS_LENGTH_SEMANTICS=CHAR, Oracle reserves 3 bytes per character (max length for a character in UTF8). So if a column is defined as VARCHAR2(30) it reserves 90 bytes, but you still can't insert more than 30 characters.

This behavior is used for PL/SQL variables also. For PL/SQL code variables is sized depending on what NLS_LENGTH_SEMANTICS is set to during compile time, so just changing NLS_LENGTH_SEMANTICS does not affect PL/SQL code. It must be recompiled to be changed. Tables must be recreated to be changed and views are not affected at all.

Note: This means that when using an Unicode database character set in IFS Cloud you need to set NLS_LENGTH_SEMANTICS=CHAR before creating any IFS Cloud database object.

Application Specific Considerations

Finance

Specific Unicode related restrictions exists within IFS Finance when using the export to file functionality. When creating payment information files that are to be sent to a payment institute, it is important to note that the characters written in the out file will be the same as the ones represented in the database. This, since the client has full Unicode support. It is important to understand that if the output file is to be sent to for instance a bank, then the file can only be handled if the receiver (e.g. the bank) can handle Unicode characters.