Icon Internationalization

Character Sets Supported
ElevateDB supports the Windows ANSI and Unicode character sets. The Windows ANSI character set is based upon an applicable locale's code page and is an 8-bit character set. The Unicode character set is the standard ISO 10646 character set and is a 16-bit character set.

ElevateDB supports these two character sets as both an engine-level and session-level option, with the session-level option inheriting the engine-level setting, by default. A session can only access configuration files and databases that use the same character set that is specified for the engine/session. However, you can mix sessions using different character sets within the same application or server.

Character Encodings
At this time, ElevateDB does not completely support using double-byte character set encodings (DBCS) with the ANSI character set, nor does it completely support using the UTF-16 encoding (Unicode surrogate pairs) with the Unicode character set. Specifically, operators such as the LIKE operator may not work properly. This means that one should assume straight single-character comparisons for both the ANSI character set and the Unicode character set, effectively making UCS-2 the only Unicode encoding completely supported.

This will change in the near future and complete DBCS and UTF-16 support will be made available.

ElevateDB supports table column and indexed column collations. Collations specified for a table column affect all column comparisons. When a table column is indexed, by default the table column collation is used for the index. If the table column collation is overridden when the index is created using the CREATE INDEX or CREATE TEXT INDEX statement, then the new indexed column collation in conjunction with the a specific SQL JOIN or WHERE expression determines whether the index column can be used by the ElevateDB SQL optimizer to optimize the expression by using the index. Please see the Optimizer topic for more information on how collations affect index selection in the optimizer. Also, the index column collation affects whether the index can be used to return a sensitive result set cursor for SELECT statements with an ORDER BY. Please see the Result Set Cursor Sensitivity topic for more information.

To specify a collation for a table or index column, you must use the COLLATE clause:

COLLATE <CollationName>

The COLLATE clause is supported for any CHAR, VARCHAR, or CLOB column. In addition, the collation name can be specified with additional modifiers. Each of the modifiers is added to the collation name using the underscore as a separator

Collation ModifierDescription
CISpecifies that any case differences between characters are ignored.
AISpecifies that accents are ignored and only base characters are considered.
KISpecifies that any Japanese hiragana/katakana character differences are ignored.
WISpecifies that the equivalent single-byte and double-byte character should be considered equal, even though they are encoded differently.

For example, to specify a case-insensitive English (United States) collation for a column, you would use the following SQL:


The available collations in ElevateDB are dynamic and reflect the available installed locales in the operating system. In addition, ElevateDB includes one default collation:

ANSI   ANSI (Binary)
UNI   Unicode (Binary)

depending upon whether the engine and/or session is using the ANSI or Unicode character set.

Warning Linux implementations of ElevateDB only support the default ANSI and UNI collations, and any attempts to use an existing database that references other collations available on Windows only will result in errors.

This default collation uses the ANSI or Unicode ordinal values for each character comparison. Upper-casing and lower-casing is done using US and Western European casing rules.

Information The AI (accent-insensitive), KI (Kana-insensitive), and WI (width-insensitive) collation modifiers described above are not applicable to the default ANSI or Unicode collations.

You may query the system-created Configuration database to get a list of available collations. All available collations in the operating system are stored in the Collations table in the Configuration database. For example, the following SELECT statement returns all of the available collations:

SELECT * FROM Configuration.Collations

Information You will receive an error if you try to open a database that has table columns or index columns that reference a collation that is not available on the operation system being used.