View Full Version : Logische mit CCSID273 auf CCSID13488
Hallo an Alle,
ich habe eine Datei mit Feldern G CCSID 13488, und will eine logische(bzw. eine View) erstellen, die diese Felder als A CCSID 273 darstellt.
ich habe versucht eine View zu erstellen mit CAST. Das ging überhaupt nicht, da hatte ich immerwieder irgendwelche Probleme.
habe jetzt eine lf erstellt mit folgender def:
R FmtF1 PFILE(tabG)
feld1 R
feld2 R
feld3 A CCSID(273)
...
feld10 Z
K feld3
K feld7
S feld4 values('','','')
mit lf arbeitet jetzt mein RPGLE Programm und hat mit einer Abfrage direkt auf ein Feld kein Problem.
Nur wenn ich Abfragen über den Navigator mit einem "Join" oder mit "oder by" oder "month" oder bei "kein Ergebnis" absetze, funktioniert es nicht. Wenn ich dann die Abfrage abbreche, bekomme ich den SQLSTATE 57011. Für was das SQLSTATE 57011 steht, habe ich nachgelesen. Bin aber nicht zufrieden mit einer Fehlerbehebung. Ich habe das Gefühl das meine Logische nicht richtige aufgebaut ist?
Kann mir jemand hier einen Tipp geben?
M.E. hast Du in dem Unicode Feld Daten, die sich nicht in alpha darstellen lassen.
Wie hast Du versucht mit CAST den Unicode zu konvertieren. Ich habe es gerade bei einer unserer Tabellen (unter Release V5R4) versucht, ohne Probleme.
CREATE VIEW MyView
As (Select ... Cast(MyUnicode as Char(256) CCSID 273)) MyFld ...)
Birgitta
M.E. hast Du in dem Unicode Feld Daten, die sich nicht in alpha darstellen lassen.
Nein, es sind ganz normale Texte.
Wie hast Du versucht mit CAST den Unicode zu konvertieren. Ich habe es gerade bei einer unserer Tabellen (unter Release V5R4) versucht, ohne Probleme.
genauso. Wenn ich die Tabelle aufrufe ist es ok. Aber wenn ich eine Abfrage auf ein Feld starte, bekomme ich die selben Probleme. Nur wenn ich ein "Order by" versuche kriege ich das SQLSTATE 57014.
Das Programm hat auch hier auf den ersten Blick kein Problem. Nur scheint es mir um einiges langsamer zu sein. Vielleicht liegt es daran,dass ich noch kein Index habe.
Unabhängig von deinem Problem ist ein CAST auf 273 vollkommen unnötig.
Wenn du deinen Job zur Laufzeit auf CCSID 273 änderst und per SQL auf die Felder zugreifst wandelt SQL automatisch in die JOB-CCSID um wenn deine Hostvariable keine UCS2-Variable ist.
Mittels eines NULL-Anzeigers kann man sogar erfahren, ob bei der Konvertierung Zeichnverluste aufgetreten sind (-1 = NULL, -2=Datenfehler).
Zusätzlich kann auch über das Feld, falls es in Order by oder Where verwendet wird in einem Index verwendet werden.
Für die View kann man sowieso keinen Index anlegen.
Für eine Abfrage im OpsNav macht ein Cast auf 273 ebensowenig sinn, da hier automatisch volle Unicodeunterstützung gewährleistet ist.
Wofür benötigst du also eine View mit CAST auf 273 ?
Vielen Dank an B.hauser und an Fuerchau,
Unabhängig von deinem Problem ist ein CAST auf 273 vollkommen unnötig. ?
Ich benötige keine View mit Cast 273. Ich habe jetzt eine ganz normale Vew erstellt. Im OpsNav läufts einwandfrei, aber im Programm hab ich ein Zeichenumsetzungproblem mit SQL0332.
Gruß,
Inchic
Ein Umsetzungsproblem besteht dann, wenn dein Job mit CCSID 65535 läuft!
Stelle deinen Job per CHGJOB CCSID(273) um.
Du kannst die View auch mit STRSQL testen. Wenn dein Job eine korrekte CCSID hat, kann auch STRSQL die Daten anzeigen.
Hallo Fuerchau,
vielen Dank für den Tip.
Ich habe es jetzt nicht gemacht, sondern die Alternative mit der einfachen LF vorgezogen. Es scheint jetzt auch gut zu laufen.
Danke nochmals.
Hallo Fuerchau,
jetzt sind bei mir doch noch zwei Probleme mit der Logischen aufgetreten.
1. Problem: wenn ich ein select auf einen Satz der nicht existiert mache, dann läuft er ins endlose bis ich abbreche.
2. Wenn ich im Programm ein SETLL aufsetze und möchte die Sätze aufsteigend haben. Dann kann es pasieren das ich keine Sortierung habe. es wird ein Satz mit einer kleineren ID und neueren Timestamp als erstes angezeigt. Und dann kommt mal wieder die richtige Sortierung. Wieso kommt er mit der sortierung durcheinander?
Gruß,
inchic
Hast du jetzte eine LF bzw. einen Index oder eine View erstellt ?
Eine View ist unsortiert und muss, wenn du eine Sortierung brauchst mit SQL und Order By gelesen werden.
Bei einer LF/Index prüfe die Schlüsselfelder.
Unicode-Felder haben ggf. bei Umlauten und sprachlichen Sonderzeichen eine andere Sortierung als SBCS-Daten.
Hier hilft ggf. eine Sorterung im Index/LF nach Spachen-Id.
Diese ist allerdings nicht casesensitiv, d.h., dass Klein/Großbuchstaben gleichwertig sortiert werden und Sonderzeichen einsortiert werden:
A a Á á À à Ä ä B b usw.
Ein Select bzw. Fetch, der keine Daten liefert kann nicht ins Endlose laufen sondern es gib einen SQLCOD 100.
Prüfe also deine Programmlogik.
Hier hilft ggf. eine Sorterung im Index/LF nach Spachen-Id.
Danke für die Tips!
Ich habe eine LF und habe die Sortierung nach Sprachen-ID definiert. Jetzt geht es.
Danke !