Charset is assumed to be the same per CUBRID instance. Providing direct UTF-8 input from a client through CCI-JDBC is possible to a CUBRID instance started with UTF-8 charset. This is due to charset conversions (when CUBRID is using ISO charset, all input is assumed ISO and is converted to UTF-8, even client native UTF-8 strings). ASCII compatible characters are fully compatible with both ISO and UTF-8, and will not suffer any transformation.
COLLATE keyword modifier is not supported in ORDER BY, GROUP BY, operators using collation, etc. As an workaround, explicit CAST operator can be used to change the collation and charset in expressions.
COLLATE is not supported on tables (setting collation at table level as default collation of all attributes of the table).
Collation is supported only on string types, ENUMERATION type does not support collation.
LIKE operator does not work as expected on case insensitive collations; LIKE matching function checks characters.
CUBRID allows (but it should not) starting an instance (server, CAS, CSQL) with different collations than the ones used to create the databases. This could lead to incoherent behavior and even crashes.
Query plans printing: collation is not displayed in plans for results with late binding.
Only the Unicode code-points in range 0000-FFFF (Basic Multilingual Plan) are normalized.
Several locales shared libraries cannot be used on one database instance at the same time.
Optimization of string prefix key (index nodes) for collation with expansions is not supported yet; there is an overhead to use the whole string as a prefix.
“French order” is not supported. It requires backwards sorting for level 2 of UCA, but it is not supported yet.
Case compare should be enhanced to cover the cases when both case multipliers are used.
Some locales use space character as separator for digit grouping (thousands, millions, ..).
Space is allowed but not working properly in some cases of localized conversion from string to number.