E1: TDA: SQL Server Database Collation (For checking width of characters at database level, for example English vs Kanji) (Doc ID 654620.1)

Last updated on JUNE 13, 2024

Applies to:

Symptoms

Customer has Japanese end-users using a combination keyboard that allows them to enter Kanji & English characters. For example, in P01012, search type field is validated via UDC 01/ST and one of the valid UDC value is J for Jobs and the Japanese end-users are supposed to enter the English-based character J. However by mistake they enter the Kanji J character instead, both web & windows client does not fail in the UDC validation and the database therefore stores an invalid Kanji J character in F0101.ABAT1 instead of the English J character. This data then causes problem when the invalid Kanji J character is exported to a text file for data export. Customer states the UDC validation should fail when the Kanji J character is entered because the unicode value is 65322 for Kanji J and 74 for English J. The EnterpriseOne data sources are set to Unicode and the database is SQL 2000 SP3a.

Changes

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.