Consider working with Unicode-mode applications only if you have any of the following situations:
You need to enable users with different languages to view, in their own languages and character sets, information from a common database. For example, using alias tables in Japanese and German, users in Japan and Germany could view, in their own languages, information about a common product set.
You need to handle artifact names longer than non-Unicode-mode applications support. For example, application and database names need to be larger than eight characters or, if you are working with a multi-byte character set, you need to handle more characters in artifact names.
You have experienced what is called the “round-trip” problem. The round-trip problem can occur in communications between multi-byte operating systems and application programs where two different bit values can map to the same character. As Java applications, Oracle Essbase Administration Services and Oracle Hyperion Provider Services always work in Unicode. No encoding conversions occur when these clients work with Unicode-mode applications and UTF-8-encoded text files; hence no round-trip conversion errors.
When deciding on using Unicode-mode applications, you should also consider the following points:
Using non-Unicode text files with Unicode-mode applications requires an understanding of locales and care in managing to them. To prevent errors that could cause database corruption, using UTF-8-encoded files is recommended. For details, see the Oracle Essbase Database Administrator's Guide.
To work with Unicode-mode applications, custom client applications that were written to support non-Unicode-mode applications must be built to use the longer string lengths used by Unicode-mode applications. This may be a simple re-build or may involve re-programming, depending on the design of the applications. Also, depending on how they are coded, the new client applications may require more memory.