| Informix DataBlade API Programmer's Manual Using the DataBlade API |
|
|
Internationalization of DataBlade API ModulesFor your DataBlade API module to work in any Informix locale, you must implement your DataBlade API module so that it is internationalized. That is, the module must not make any assumptions about the locale in which it will execute.
A C UDR inherits the server-processing locale as its current processing locale. The database server dynamically creates a server-processing locale for a particular session when a client application establishes a connection. The database server uses the client locale, database locale, the server locale, and information from the client application to determine the server-processing locale. For more information on how the database server determines the server-processing locale, see the Informix Guide to GLS Functionality. 
A client LIBMI application performs its I/O tasks in the client locale. Any database requests it makes execute on the database server. Therefore, they execute in the server-processing locale.
This section provides the following information about how to internationalize a C UDR:
An internationalized C UDR must handle the following GLS considerations.
| GLS Consideration for an Internationalized UDR | DataBlade API Function |
|---|---|
| What considerations must the C UDR take when copying character data? | None |
| How can the C UDR access GLS locales? | Informix GLS function library |
| How does the UDR handle code-set conversion? | mi_get_string(), mi_put_string() Informix GLS function library |
| How does the UDR handle locale-specific end-user formats? | mi_date_to_string(), mi_decimal_to_string(), mi_interval_to_string(), mi_money_to_string(), mi_string_to_date(), mi_string_to_decimal(), mi_string_to_interval(), mi_string_to_money() |
| How can the C UDR access internationalized exception messages? | mi_db_error_raise() |
| How can the C UDR access internationalized tracing messages? | GL_DPRINTF, gl_tprintf() |
| How do opaque-type support functions handle locale-sensitive data? | mi_get_string(), mi_put_string() |
For more information on how to handle these GLS considerations within a C UDR, see the chapter on database servers in the Informix Guide to GLS Functionality.
Tip: DataBlade API modules can also use the functions of the Informix GLS library to access GLS locales. For more information on the Informix GLS library, see the "Informix GLS Programmer's Manual."
Illustra Compatibility
The mi_wchar data type is a legacy data type that holds wide characters. Wide character are an alternative form for the processing of multibyte characters. A wide-character form of a code set involves the normalization of the size of each multibyte character so that each character is the same size.
Tip: The DataBlade API continues to support mi_wchar for backward compatibility with the Illustra (16-bit) applications. All new DataBlade API modules should use the gl_wchar_t data type of the Informix GLS library. For more information on the use of gl_wchar_t, see "Informix GLS Programmer's Manual."
If you are converting an Illustra application that uses mi_wchar, keep the following points in mind:
On Solaris UNIX, the gl_wchar_t data type is 32 bits long. 
On Windows NT, the gl_wchar_t data type is 16 bits long.