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 OCTOBER 24, 2022
Applies to:JD Edwards EnterpriseOne Tools - Version 8.93 and later
Information in this document applies to any platform.
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.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document