Siebel Global Deployment Guide > Overview of Global Deployments > Global Deployment Terminology >

Platform

This topic is part of Global Deployment Terminology.

The platform determines what data can be processed in a Siebel Business Applications deployment. The character set encoding and operating system language of a platform will determine what data can be handled correctly and what data will not be handled correctly by the platform.

This guide uses the term platform in several places to discuss deployment options as well as specific functionality available in Siebel Business Applications.

Siebel Business Applications generally do not support mixed character encoding environments. The reason is that it is not technically possible to manage an environment that uses multiple character set encodings on databases and servers without a genuine risk of losing data in the process.

For example, suppose a database is set up with a Western European character set encoding and a user tries to insert Japanese data through a Siebel Server set up for Japanese. Depending on the actual database, the effect could be that the user's data would be rejected and not stored in the database, or the data could get converted by the database and stored incorrectly as unreadable characters (substitution characters), resulting in loss of the original Japanese data.

In some cases a user may try to enter data into the application and receive an error message saying that the language of the text entered "is not compatible with the database language" or that the length of the text entered "is bigger than the corresponding length allocated in the database."

The above error may occur when the character set of the data does not match the character set of the database, and cannot be converted without data loss. Or, the error may occur when the data string is too long to fit into the database column.

If you have an existing Siebel deployment and upgrade the database default character set to Unicode (any encoding), all links to other IT systems must be examined for compatibility. In many cases, data previously encoded in a traditional codepage will now be larger in terms of bytes, and will overflow fields used for transfers. In such cases, Siebel Unicode data values will be truncated, especially if the data value is large enough to approach the maximum defined size of the field.

Field sizes in EAI or EIM tables, as well as field sizes in any linking or replication software must be examined. Extension columns that have been added to the system must also be examined.

Depending on your existing code page, the languages and specific characters representing your data, and the Unicode encoding you are migrating to, field sizes may need to be enlarged. In some scenarios, field sizes must be doubled.

When specifying new field sizes, be careful as to whether they must be given in bytes or in characters. Field size units will vary by the RDBMS vendor:

• Oracle 10g. Specify field sizes in CHARACTERS.
• IBM DB2 UDB. Specify field sizes in BYTES.
• IBM DB2 UDB for z/OS. Specify field sizes in BYTES.
• MS SQL Server. Specify field sizes in BYTES.

NOTE:  For more information about using IBM DB2 UDB for z/OS, see Implementing Siebel Business Applications on DB2 UDB for z/OS and Siebel Database Upgrade Guide for DB2 UDB for z/OS.

Considerations for Deployments Using Shift-JIS

Below are special considerations for Japanese-language deployments using Shift-JIS, which is also known as Code Page 932 (or 936 on DB2, or JA16SJIS on an Oracle database).

• If your database uses Code Page 932 (Shift-JIS), it is strongly recommended to set the parameter UseANSIControlsForCP to CP932 for the Application Object Manager component.

  If you do not set the parameter in this way, users may sometimes be able to enter more text in a field than will be saved in the database. This parameter applies only for high-interactivity clients. It is assumed that the client machine uses the same code page as the database.

• If your deployment is migrating from Code Page 932 (Shift-JIS) to Unicode, customers must be careful with characters entered on a system where the data is stored in Code Page 932.

  Over 300 characters present in Code Page 932 have only one representation in Unicode, so when these characters are moved to a Unicode system, they are converted permanently to the new value used in Unicode. Because of this conversion, users will see that the character they originally entered has been slightly changed, but the meaning should be the same as before.

  An example is the replacement of the WAVE DASH character by the FULL WIDTH TILDE character, often used in expressing appointment times. There is no correction for this situation—it is a result of the design of both Code Page 932 and Unicode character sets, which are industry standards.