SQL Index DBCS-fähig

[BenderD]

das mit dem "G" in der DDS hatte ich komplett verdrängt. :-)

Ich wollte eigentlich nur ausdrücken, dass, wenn man heute eine internationale Anwendung erstellt, alles, wo "DBCS" oder "Graphic" draufsteht, getrost ignorieren kann, das bringt einen nicht weiter.
Zumindest nach meiner Erfahrung.

(Wenn wir schon bei i-Pünktchen sind: "Unicode" ist der eine, ganz große Zeichensatz. UTF ist eine mögliche Kodierung.)

Habe gerade eine kleine Test-Datei erstellt, ein DSPFD des Index sagt "DBCS-fähig: Ja". (V7R1)

CREATE TABLE TESTU (FELD1 VARgraphic (10 ) CCSID 13488 NOT
NULL WITH DEFAULT)                                                 
CREATE INDEX testu1 ON TESTu (FELD1) 

... meine Rede: Bug => Fehlermeldung an IBM.

Ich denke, ihr machts euch ein bisschen einfach:

UCS2 und UCS4:= Unicode für Arme und Kranke
- Subset von Unicode mit feste Länge von jedem Zeichen
- für Indexbäume relativ ein´fach handhabbar

UTF8 und UTF16:= the real stuff
- kann heute (und in absehbarer Zukunft) alle Zeichen
- arbeitet mit variabel langer Codierung
- "häufige" (bei UTF8 wenige, bei UTF16 ala UCS2) Zeichen fix codiert
- "seltene" Zeichen mit einer Art escaped Entity Darstellung
- gleich aussehende Zeichen können unterschiedlche Codierungen haben
- für Indexbäume problematischer

D*B