Graphic data in Japanese or Traditional Chinese EUC applications

The information that follows describes EUC application development considerations for graphic data, including graphic constants, graphic data in UDFs, stored procedures, DBCLOB files, and collation:
  • Graphic constants

    Graphic constants, or literals, are actually classified as mixed character data, as they are part of an SQL statement. Any graphic constants in an SQL statement from a Japanese or Traditional Chinese EUC client are implicitly converted to the graphic encoding by the database server. You can use graphic literals that are composed of EUC encoded characters in your SQL applications. An EUC database server will convert these literals to the graphic database code set, which will be UCS-2. Graphic constants from EUC clients should never contain single-width characters, such as CS0 7-bit ASCII characters or Japanese EUC CS2 (Katakana) characters.

  • UDFs

    UDFs are invoked at the database server, and are meant to deal with data encoded in the same code set as the database. In the case of databases running under the Japanese or Traditional Chinese code set, mixed character data is encoded using the EUC code set under which the database is created. Graphic data is encoded using UCS-2. UDFs need to recognize and handle graphic data that is encoded with UCS-2.

    For example, assume that you create a UDF called VARCHAR, and the UDF converts a graphic string to a mixed character string. The VARCHAR function has to convert a graphic string encoded as UCS-2 to an EUC representation if the database is created under the EUC code set.

  • Stored procedures

    A stored procedure running under a Japanese or a Traditional Chinese EUC code set must be able to recognize and handle graphic data that is encoded using UCS-2. With these code sets, graphic data that is either received or returned through the stored procedure's input/output SQLDA is encoded using UCS-2.

  • DBCLOB files
    The important considerations for DBCLOB files are:
    • The DBCLOB file data is assumed to be in the EUC code page of the application. For EUC DBCLOB files, data is converted to UCS-2 at the client on read, and from UCS-2 at the client on write.
    • The number of bytes read or written at the server is returned in the data length field of the file reference variable. The number of bytes is based on the number of UCS-2 encoded characters that are either read from or written to the file. The number of bytes actually read from or written to the file might be larger than the server writes in the data length field.
  • Collation

    Graphic data is sorted in binary sequence. Mixed data is sorted in the collating sequence of the database applied on each byte. Because of the possible difference in the ordering of characters in an EUC code set and a DBCS code set for the same country or region, different results might be obtained when the same data is sorted in an EUC database and in a DBCS database.