GLS support

When the database server starts a UDR, the routine runs in the locale that DB_LOCALE specifies. Consequently, the database server automatically converts parameters, return values, and output values between the DB_LOCALE code set and the Unicode code set so that Java™ code can use the values.

However, when a Java UDR creates a JDBC connection to the database server for access through SQL, you can set DB_LOCALE into the connection URL to control conversions and formatting between the Unicode code set and the code set of the database server locale. This setting of DB_LOCALE overrides any environment settings. In fact, DB_LOCALE does not need to be set in the environment. Similarly, you can also set DBDATE, GL_DATE, and DBCENTURY into the URL connection to control date conversion and formatting.

For example, when a UDR sends string or date data to the database server in an insert, the database server converts the data from Unicode to the locale that DB_LOCALE specifies, or it interprets dates and intervals by using your DBDATE or GL_DATE setting.

When the database server returns data to the Java UDR, the database server does the opposite conversion, so Java code sees only Unicode.

You can extend the Java runtime environment that is distributed with server. You can extend the default list of character sets by creating a JAR file that contains your own CharsetProvider and Charset class implementations. Copy the custom CharsetProvider JAR file into the $ONEDB_HOME/extend/krakatoa/jre/lib/ext directory. For more information about how to build a custom CharsetProvider JAR file, see that Java API documentation for CharsetProvider.

Important: This method must be used only for situations where the server supports a character set that does not have an equivalent (or does not exist) within the Java runtime environment that is distributed with server.