Japanese or Traditional Chinese EUC, and UCS-2 Considerations in C and C++ embedded SQL applications

If your application code page is Japanese or Traditional Chinese EUC, or if your application connects to a UCS-2 database, you can access GRAPHIC columns at a database server by using either the CONVERT or the NOCONVERT option with wchar_t or sqldbchar graphic host variables or input/output SQLDAs.
In this section, DBCS format refers to the UCS-2 encoding scheme for EUC data. Consider listed cases:
  • CONVERT option used

    The Db2® client converts graphic data from the wide character format to your application code page, then to UCS-2 before sending the input SQLDA to the database server. Any graphic data is sent to the database server tagged with the UCS-2 code page identifier. Mixed character data is tagged with the application code page identifier. When graphic data is retrieved from a database by a client, it is tagged with the UCS-2 code page identifier. The Db2 client converts the data from UCS-2 to the client application code page, then to the wide character format. If an input SQLDA is used instead of a host variable, you are required to ensure that graphic data is encoded using the wide character format. This data will be converted to UCS-2, then sent to the database server. These conversions will impact performance.

  • NOCONVERT option used

    The graphic data is assumed by Db2 to be encoded using UCS-2 and is tagged with the UCS-2 code page, and no conversions are done. Db2 assumes that the graphic host variable is being used as a bucket. When the NOCONVERT option is chosen, graphic data retrieved from the database server is passed to the application encoded using UCS-2. Any conversions from the application code page to UCS-2 and from UCS-2 to the application code page are your responsibility. Data tagged as UCS-2 is sent to the database server without any conversions or alterations.

To minimize conversions you can either use the NOCONVERT option and handle the conversions in your application, or not use GRAPHIC columns. For the client environments where wchar_t encoding is in two-byte Unicode, for example Windows 2000 or AIX® version 5.1 and higher, you can use the NOCONVERT option and work directly with UCS-2. In such cases, your application might handle the difference between big-endian and little-endian architectures. With the NOCONVERT option, Db2 database systems use sqldbchar, which is always two-byte big-endian.

Do not assign IBM® eucJP/IBM eucTW CS0 (7-bit ASCII) and IBM eucJP CS2 (Katakana) data to graphic host variables either after conversion to UCS-2 (if NOCONVERT is specified) or by conversion to the wide character format (if CONVERT is specified). The reason is that characters in both of these EUC code sets become single-byte when converted from UCS-2 to PC DBCS.

In general, although eucJP and eucTW store GRAPHIC data as UCS-2, the GRAPHIC data in these databases is still non-ASCII eucJP or eucTW data. Specifically, any space padded to such GRAPHIC data is DBCS space (also known as ideographic space in UCS-2, U+3000). For a UCS-2 database, however, GRAPHIC data can contain any UCS-2 character, and space padding is done with UCS-2 space, U+0020. Keep this difference in mind when you code applications to retrieve UCS-2 data from a UCS-2 database versus UCS-2 data from eucJP and eucTW databases.