We have added search box. Key in SAP OSS Notes no. or keyword to search
TopBottom

Note: Please share your thoughts on any sap oss note by replying .

SAP Note 19689 - ORACLE , CODEPAGE , access to external data

SAP Note 19689 - ORACLE , CODEPAGE , access to external data
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Symptom:

The customer wants to create an Oracle database. For this purpose the codepage needs to be specified in which the database is operated.
The SAP standard is US7ASCII code (7-bit ASCII). ORACLE will also accept characters above the 7-bit code.
The ORACLE (SQL-NET) network component vob converts data between the database server and the application server if the application runs with another codepage than that defined for the database. Unfortunately all characters that are not 7-bit ASCII are not handled correctly by the NLS conversion from US7ASCII to any other codepage.
Therefore the SAP System can only be operated correctly if no conversion takes place between the SAP application server and the database.
Two questions frequently occur in this context.

    1. Can SAP customers choose a codepage other than US7ASCII during the installation?
    2. Can customers access external data from within the SAP System which reside in an ORACLE database with a codepage other than SAP's codepage?
Cause and prerequisites

None

Solution
    1. Customers can run the SAP System with codepages other than US7ASCII. The codepage in which an application program runs (from an Oracle point of view) is determined by an environment variable "NLS_LANG". If this environment variable is not set, the machine keyboard configuration is assumed as a default.
    The content of the environment variable consists of 3 elements:
      a) NLS-LANGUAGE
      Determines the sort sequence.
      b) NLS-TERRITORY
      Determines the default date format
      the decimal separator (. or ,)
      c) Codepage
      Determines the character set.


In the SAP System it must be ensured that data is provided in binary sort sequence with order by clauses and the decimal point is used as a separator (coded in the kernel).

To run the SAP R/3 System with a non-US7ASCII database, proceed as follows:

    • Change the environment of the ADM- and ORA users. Set the variable NLS_LANG:
      NLS_LANG = AMERICAN_AMERICA.WE8DEC ensures that:
      a) "order by" always provides data in binary sort sequence.
      b) the period "." is used as a separator for decimal places.
      c) No codepage conversion takes place between the SAP System and the database.

Since SAP usually works with the codepage ISO8859 and the ASCII representation is identical with the WE8DEC representation, it is also possible to IMPORT an SAP-7BIT EXPORT to a database defined with the codepage WE8DEC without losing special characters.

    2. Unfortunately this is not easy to do. In an SAP standard installation the SAP System is run with US7ASCII. When another Oracle database is accessed via database link, which was created in a national CODEPAGE (for example, WE8DEC), all characters (for example, umlauts) whose ASCII representation is above 127 are not converted correctly. The problem could be avoided by setting the environment variable NLS_LANG (e.g. GERMAN.GERMANY.WE8DEC) to the converted codepage of the target database. However, it is then no longer possible to access the SAP umlauts because of the conversion.

The only solution for this problem:

    • Run the SAP System in a CODEPAGE in which the conversion in connection
with external access is no problem (for example, same codepage as that
of the external system).

0 comments:

Post a Comment