SQL Index DBCS-fähig

[BenderD]

Hallo Gemeinde,

wie schaffe ich es das ein SQL Index (CREATE INDEX) DBCS-fähig wird?
Was muss ich da im Statement angeben?

sollte dann so aussehen (DSPFD):
Datenbankdateiattribute
Extern beschriebene Datei . . . . . . . . . : Ja
SQL-Dateiart . . . . . . . . . . . . . . . : INDEX
Dateiebenen-ID . . . . . . . . . . . . . . : 1101215084231
Erstellungsdatum . . . . . . . . . . . . . : 15.12.10
Text 'Beschreibung' . . . . . . . . . . . . : TEXT
Verteilte Datei . . . . . . . . . . . . . . : Nein
Partitionierte SQL-Tabelle . . . . . . . . : Nein
DBCS-fähig . . . . . . . . . . . . . . . . : Ja

Danke schon mal!!

LG

... bei mir funzt das unter Release 5.4 (hab' grad nix anderes zur Hand) voll elektrisch, bist Du sicher, dass das kein bug, sondern ein Feature ist?

D*B

[XMan]

@BenderD

Tja, das kann ich leider nicht feststellen ob dies ein Bug ist.
Ich sehe nur das dieser Index vor V7R1 erstellt wurde. Erstelle ich den Index jetzt mit V7R1 wieder, so sehe ich dieses Attribut nicht mehr als "DBCS fähig", was auch immer das heisen mag.
Habe die Zugriffe kontrolliert die nun auf den "neuen" Index los gehen, da habe ich keine Fehler festgestellt.

SQL dürfte hier beim Erstellen eines Indexes nicht mehr auf die Graphic Felder in der PF Datei prüfen.
Erstelle ich eine PF Datei mit einem Graphic Feld so ist das Attribut "DBCS fähig" auf "JA" gesetzt.

Ich nehme das mal so hin, den bisher habe ich noch keine negativen Auswirkungen festgestellt.

LG

[Fuerchau]

Ich denke mal, dass die CCSID 13488 nicht mehr direkt als DBCS gesetzt wird, da diese ja inzwischen als UCS2 direkt unterstützt wird (Typ National).
Somit wird das Attribut nun nicht mehr benötigt, da bei Abfragen die Konvertierung ggf. automatisch erfolgt.

[Anton Gombkötö]

DBCS scheint nur die "alte" Lösung von IBM zur Darstellung von Fernost-Zeichensätzen zu sein, mit Wurzeln, die älter als die AS/400 sind.

Die Tatsache, dass z.B. Unicode-Zeichensätze auch mehrere Bytes belegen können (es sind ja nicht immer zwei) hat mit dem alten ("Produkt"-)Namen überhaupt nichts zu tun.

Ich habe leider keinen Zugriff mehr auf die Dateien meines letzten Arbeitsgebers, da hat es vor UCS-2-Feldern nur so gewimmelt, aber ich traue mich eigentlich wetten, dass da weit und breit nichts von DBCS steht.

UCS-2-Felder sind auch keine graphischen Felder.

[Fuerchau]

Unicode ist entweder UCS2 oder UCS4.
Variabel lang ist da nichts.
Variabel sind UTF-8 (1-4 Byte) und UTF-16 (2 - 6 Byte).

UCS2 muss immer noch als (var)graphic (erst ab V7 als "national char", "nchar", nvarchar") definiert werden.

DBCS-Zeichensätze gibt es allerdings immer noch und können auch weiterhin verwendet werden.

[Anton Gombkötö]

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) 

[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

[Fuerchau]

Die Speicherung in UTF-8 ist ja ganz nett, aber je nach Implementation scheitert man dann spätestens beim Vergleich, wenn die zu vergleichende Zeichenfolge nicht auch UTF-8 ist.
In diesem Fall wird ggf. unter Verlusten in UCS2 konvertiert.

Auch der SUBSTR von UTF8 ist von der Implementierung abhängig.
Ggf. wird in UCS2 umgewandelt, der SUBSTR durchgeführt und in UTF8 zurückgewandelt.
Es kann aber auch schiefgehen.

Native UTF8/16-Zeichenfolgen werden eher im Programm in Strings (UCS2) vor der weiterverarbeitung konvertiert.

Ich habe da noch keine UCS4-Implemtierung gesehen, die dies alles korrekt behandeln würde.

Zumindest für die reine DB-Speicherung würde ich von UTF8 abraten.

Wobei Oracle generell NCHAR's als UTF-8 speichert und die Länge dabei in "Bytes" und nicht in "Zeichen" angegeben wird.
Also NCHAR(1) geht zwar, aber kann halt keine Sonderzeichen wie Umlaute aufnehmen.

[andreaspr@aon.at]

Wobei Oracle generell NCHAR's als UTF-8 speichert und die Länge dabei in "Bytes" und nicht in "Zeichen" angegeben wird.

Wie das Oracle Speichert UTF-8, UTF-16 (und ich glaube auch UCS2) wird bei der Installation der Datenbank festgelegt und kann im nachhinein auch nicht mehr einfach geändert werden.