Logische mit CCSID273 auf CCSID13488

[Fuerchau]

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 ?

[inchic]

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

[Fuerchau]

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.

[inchic]

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.

[inchic]

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

[Fuerchau]

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.

[inchic]

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 !