IBM Support

Using Oracle as an ODBC datasource, a TI process cannot import language specific characters like german special characters ("Umlaute") or crashes the TM1 server process

Troubleshooting


Problem

You are using an Oracle database as an ODBC datasource for a TI (Turbo Intgrator) process. The ODBC connection, the DSN to connect to your Oracle database, has been created using the free Oracle Instant ODBC Client, made up of the Oracle Basic Client Package and the optional Oracle ODBC Client Package. Language specific characters like german mutant vowels ("Umlaute") are displayed in the Preview of the TI Editor, but are lost or corrupted when the TI process is executed. It may also happen that to execute the TI process fails with a TM1 server crash. Selecting the checkbox "Use Unicode" in the first tab "Data Source" of the TI Editor does not resolve the issue.

Environment

TM1 9.5.1 Turbo Integrator

Resolving The Problem

Contact your Oracle database administrator and ask for the Locale set on the Oracle database server machine using the environment cariable NLS_Lang, for instance NLS_LANG=GERMAN_GERMANY.WE8ISO8859P1 . On the server machine running the TM1 server process and the Oracle Instant ODBC Client, create a new environment variable NLS_LANG to set the same Locale. If your TM1 server process is running on a Windows server machine, this may be either a new Windows system environment variable or a user specific Windows environment variable attached to the Windows user account running the TM1 server process.



Note:
You must check that the Locale set by the environment variable NLS_LANG is compatible with the codepage used by the operating system of the server machine running the Oracle Instant ODBC Client, see the Oracle website ->

http://download.oracle.com/docs/cd/E11882_01/server.112/e10729/ch3globenv.htm#NLSPG189
Choosing a Locale with the NLS_LANG Environment Variable

Should the NLS_LANG Setting Match the Database Character Set?

The NLS_LANG character set should reflect the setting of the operating system character set of the client. For example, if the database character set is AL32UTF8 and the client is running on a Windows operating system, then you should not set AL32UTF8 as the client character set in the NLS_LANG parameter because there are no UTF-8 WIN32 clients. Instead, the NLS_LANG setting should reflect the code page of the client. For example, on an English Windows client, the code page is 1252. An appropriate setting for NLS_LANG is AMERICAN_AMERICA.WE8MSWIN1252.

Setting NLS_LANG correctly enables proper conversion from the client operating system character set to the database character set. When these settings are the same, Oracle Database assumes that the data being sent or received is encoded in the same character set as the database character set, so character set validation or conversion may not be performed. This can lead to corrupt data if the client code page and the database character set are different and conversions are necessary.

[{"Product":{"code":"SS9RXT","label":"Cognos TM1"},"Business Unit":{"code":"BU053","label":"Cloud \u0026 Data Platform"},"Component":"TM1","Platform":[{"code":"PF033","label":"Windows"}],"Version":"9.5.1","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"Product":{"code":"SSDL22","label":"IBM Planning Analytics Express"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Cognos Xcelerator Turbo Integrator","Platform":[{"code":"","label":"Windows 2003 server"}],"Version":"9.0","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
10 November 2022

UID

swg21448873

Page Feedback