View Full Version : Sortierung Umlaute in PF
Mr.iSeries
13-09-07, 09:09
Im Query gibt es ja bei Sortierfolge wählen folgende Auswahlmöglichkeiten:
1=Hexadezimal
2=Query für iSeries Deutsch
3=Sortierfolge definieren
4=Umsetztabelle
5=Systemdefinierte Sortierfolge
Umlaute sortiert die Maschine bei Hexadezimal nach vorne.
Bei Query für iSeries Deutsch jedoch sortiert er die Umlaute richtig.
Das heißt ö kommt nach o usw.
Meine Frage:
Gibt es eine Möglichkeit die Daten in Physischen Dateien auch nach der 2. Auswahl zu sortieren?
kuempi von stein
13-09-07, 09:48
Hallo,
irgendwie entgeht mir immer der Sinn, eine PF schon mit Keyfelder zu erstellen bzw. sortiert zu haben.
Zum Glück machen wir das immer über LF.
Zu Deinem Problem könnte ich mir vorstellen, das man
ALTSEQ(TABLELIB/TABLE)
auf Dateiebene im DDS angibt, um jede gewünschte Sortierung zu erhalten, die man möchte.
Gibt bestimmt zig andere Lösungen...
k.
Mr.iSeries
13-09-07, 10:33
ok...die Frage ist nur wie muss diese Tabelle dann aussehen bzw. gibt es von IBM dafür schon eine vorgefertigte Tabelle?
Hallo,
das hier ist sicher kein Beispiel für eine "Sortierung" der PF, die man, wenn man denn, für Primary Keys verwendet und Schlüsselfelder sollten keine Umlaute oder ähnliche Spirinkel enthalten (# und $ etc schon garnicht).
Die Tables findet man übrigens hier:
Sort Sequence Tables (http://publib.boulder.ibm.com/iseries/v5r1/ic2924/info/nls/rbagssrtseq.htm)
mfg
Dieter Bender
Hallo,
irgendwie entgeht mir immer der Sinn, eine PF schon mit Keyfelder zu erstellen bzw. sortiert zu haben.
Zum Glück machen wir das immer über LF.
Zu Deinem Problem könnte ich mir vorstellen, das man
ALTSEQ(TABLELIB/TABLE)
auf Dateiebene im DDS angibt, um jede gewünschte Sortierung zu erhalten, die man möchte.
Gibt bestimmt zig andere Lösungen...
k.
Vorgefertigte Tabellen kann man mit WRKTBL ansehen.
Dort gibt es auch Sortiertabellen.
Du kannst allerdings beim "CRTLF ... SRTSEQ(...)" angeben (siehe dortigen Hilfetext).
Der Gegensatz zu ALTSEQ ist NOALTSEQ, da ggf. nicht alle Schlüsselfelder nach Sprache sortiert werden müssen.
Beim späteren Zugriff mit verschiedenen Job-CCSID's kann es da ggf. zu Problemen kommen, da je nach DB-CCSID das "Gewicht" eines Zeichens unterschiedlich sein kann.
Wenig performant ist ggf der Parameter SRTSEQ(*JOB), da dies beim Open bzw. 1. Zugriff zu einem temporären Neuaufbau des Index führt.