Kbase P98024: Having problems with length of index keys after migration to UTF-8 - error 129, 11353
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
3/19/2008 |
|
Status: Verified
FACT(s) (Environment):
OpenEdge 10.0x
OpenEdge 10.1A
SYMPTOM(s):
The total length of the fields in an index exceeds max key size. (129) (11353)
Unable to store 191 characters within an index when using UTF-8 ICU collation
Having problems with length of index keys after migration to UTF-8
The same application works fine in version 9 using -cpinternal 1250
CAUSE:
Enhancement request# 20041122-001
CAUSE:
In versions preceeding OpenEdge 10.1B, this is an expected behavior - the keys for the UTF-8 (Basic) collation consist of the bytes of the field for a case-sensitive key, or the lower-case bytes for a case-insensitive key.
These will generally be larger than single-byte keys, which are usually the same as the character length of the string, except for strings with the German sharp-ess character ('ß').
Keys using the new ICU collations will tend to be larger than UTF-8 Basic keys. The limit on key sizes is about 200 bytes and is for the entire key (all components).
FIX:
This enhancement has been implemented in the OpenEdge 10.1B in the form of the "proutil -C enablelargekeys" utility only for databases with 4KB or 8KB database blocksize. Once enabled, the new index key is limited to approximately 1970 characters.
Please refer to "OpenEdge Data Management: Database Adminstration" for further information.
Prior to OpenEdge 10.1B, the only fix is to modify the application to put a shorter string to an index or to use the BASIC collation.