Kbase P84163: Is it possible to enter English Ascii text into a non Western database?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
06/06/2007 |
|
Status: Unverified
GOAL:
Is it possible to enter English Ascii text into a non Western code page based database?
GOAL:
Is it possible to enter English Ascii text into a database using a non Western incompatible code page (e.g. 1250, 1251, SHIFT-JIS)?
GOAL:
Is it possible to avoid the 6063 error:
Code page conversion table for <table-name> to <table-name> was not found in convmap.cp. (6063)
when trying to connect Western clients and non Western clients to the same database? For example, for U.K. and Russian users to connect and use the same database, or U.K. and Japanese users to connect and use the same database?
FACT(s) (Environment):
OpenEdge 10.x
Progress 9.x
FIX:
It is possible to store English Ascii text into almost any database regardless of the code page. There are effectively two ways to do this, and the following relates specifically to GUI clients and not Webspeed clients.
1. Use a database that is based on the non Western code page. For example, if Japanese and U.K. users wanted to enter data into the same database, the database would be created using the Japanese code page SHIFT-JIS. Since all code pages contain the basic English Ascii character set in positions 0 - 127, these can be entered by any client without a problem. However, in order to do this all Progress clients must effectively be Japanese (i.e. use -cpinternal SHIFT-JIS, -cpstream SHIFT-JIS, -cpcoll basic). So, both the U.K. clients and Japanese clients would start their sessions using these startup parameters.
However, any attempt to write extended characters (non English Ascii text above position 127, such as French accented characters) from a GUI client whose Windows locale is not Japanese (i.e. the U.K. clients), will corrupt the data. Therefore, although the Japanese clients could enter both Japanese and English Ascii text, the U.K. clients must be restricted to entering only English Ascii characters (those in the range 0 - 127).
2. The other method to achieve this is to use a Unicode (UTF-8) Application database which can store all possible characters. All clients can connect to the database using their own local code page (Russian, Western, Asian, etc) and collation. So clients from all over the world can connect and use the same database. There are however two obvious problems with this configuration:
- Unicode only supports binary sorting. So any queries that are resolved on the server could return unexpected/unwanted results. To avoid this you must force client side sorting with BY COLLATE and COMPARE. This is obviously slower since all records have to be passed to the client. Another drawback due to binary sorting, is that Unicode is difficult to use with ADM2. Since SDO's run partly on the server and return records in batches, they will resolve queries using binary sorting. (See Linguistic sorting note below.)
- The second problem with this configuration is that although users from various different regions can enter data into the same database, they cannot necessarily share this data. If a Japanese user enters Japanese text into the database, this same data cannot be successfully displayed by a Western user using a Western code page, because the characters will not display correctly. Subsequently any attempt to modify and save this record by the western GUI client will corrupt the Japanese data. For this reason the application must not allow users to share data between regions using incompatible code pages.