Suchen nach Umlauten

[chs]

Ja natürlich, dann wird versucht, die Umlaute in 037 zu konvertieren.
Jetzt kommt es darauf an, auf welcher CCSID die 5250-Sitzungen eingestellt sind.
Stehen die z.B. auf 273 hast du ein großes Problem.

In diesem Fall musst du die Felder auf die passende CCSID casten:

cast(Feld as char(nn) ccsid 273) = 'Nü'

Wichtig ist, dass das System auf die Primärsprache eingestellt ist und auch die Job's und DB passend auf die Sprache bzw. 5250-Hostcodepage gestellt werden.
Dann klappts auch mit dem ODBC.

Also jetzt hast du mich verloren.

Was hat die 5250 Emulation mit einem ODBC Zugriff zu tun?

Welche Spracheinstellungen meinst du? Der Client und die AS/400 sind auf Englisch (US) eingestellt.

Was genau sollte ich auf welcher Maschine ändern? Oder wie kann ich herausfinden ob das wirklich das Problem ist.

Macht es Sinn den ODBC Treiber für Windows zu installieren 9.7 oder so? Oder wird der mit der iSeries nicht funktionieren?

[chs]

Hier vielleicht nochmal der Select zum Verständnis mit dem wir jetzt testen.
Ich tippe den Select in ein ODBC Tool ein.

Funktioniert:
Select * from SENDUNG where FELD = 'Nuernberg'

Funktioniert nicht:
Select * from SENDUNG where FELD = 'Nürnberg'

Interessanterweise geht ja der Insert und der Update mit dem Umlaut. Nur der Umlaut in der where Clause verursacht das Problem.

Frage: Wie kann man auf der iSeries sehen, welcher Select dort ankommt?

[andreaspr@aon.at]

hast du schon den Cast probiert, wie fürchau beschrieben hatte?
cast(Feld as char(nn) ccsid 273) = 'Nü'
wenn es dann funktioniert, hast du definitiv ein problem mit den CCSIDs und du brauchst nicht lang weiter suchen.

vlt. musst du auch die Language-ID in deiner ODBC-einstellung anpassen, wenn die DB mit ENU fährt.

[chs]

hast du schon den Cast probiert, wie fürchau beschrieben hatte?
cast(Feld as char(nn) ccsid 273) = 'Nü'
wenn es dann funktioniert, hast du definitiv ein problem mit den CCSIDs und du brauchst nicht lang weiter suchen.

vlt. musst du auch die Language-ID in deiner ODBC-einstellung anpassen, wenn die DB mit ENU fährt.

Ja - das habe ich wie folgt probiert:

Select * from SENDUNG where cast(FELD as char(50) ccsid 273) = 'Nürnberg'

Gleiches Verhalten. Kein Response von der Datenbank und mann muss den Job auf AS/400 Seite beenden.

Aber woher kommt die 273? Woher weiss ich dass die korrekt ist?
Wenn ich das weiss, könnte ich diese Codepage doch im ODBC Treiber angeben oder nicht?

Wo stelle ich im ODBC eine Language-ID ein?

[andreaspr@aon.at]

Gleiches Verhalten. Kein Response von der Datenbank und mann muss den Job auf AS/400 Seite beenden.

hast du schon im job-log nachgesehen, dort drinnen stand bevor du den beendet hattest?
inetressant wäre auch unter welcher CCSID dieser job gelaufen ist!

[Fuerchau]

Dann probier doch folgendes:

Select * from SENDUNG where cast(FELD as char(nn) ccsid 273) = 'Nürnberg'

wobei nn die originale Feldlänge ist.

[Fuerchau]

273 ist Deutsch.

Nochmal:
Welche Hostcodepage wird in den 5250-Sitzungen verwendet ?

Ansonsten wird wohl nichts helfen, als die V5R4-version des CA zu installieren.
Irgendwie verhält sich wohl die V6 inkompatibel zu V5R3.

[chs]

273 ist Deutsch.

Nochmal:
Welche Hostcodepage wird in den 5250-Sitzungen verwendet ?

Ansonsten wird wohl nichts helfen, als die V5R4-version des CA zu installieren.
Irgendwie verhält sich wohl die V6 inkompatibel zu V5R3.

Das mit der Hostcodepage versuche ich gerade herauszufinden.

Wir haben nun auf einem Testsystem den CA V5 installiert. Exact gleiches Verhalten.

[andreaspr@aon.at]

job-ccsid auf der as/400??

[Fuerchau]

Die JOB-CCSID auf der AS/400 im QZDA-Job ist NIE 65535 sondern wird aus der Sprachid des Users/Systems entwickelt.

Aber wieviele Sätze hat die Datei ?
Ggf. dauert die Abfrage einfach so lange.
Zusätzlich kann man ind er ODBC-Konfig noch die Diagnose (STRDBG) starten um ggf. das Joblog zu analysieren.

[chs]

Aber wieviele Sätze hat die Datei ?
Ggf. dauert die Abfrage einfach so lange.
Zusätzlich kann man ind er ODBC-Konfig noch die Diagnose (STRDBG) starten um ggf. das Joblog zu analysieren.

Die Tabelle hat 4 Zeilen :-)

Ein Select * from SENDUNG dauert gar nicht.
Mit einer where clauses auf dieses Feld (ist nur als Test gedacht), funktioniert der Select auch ohne Verzögerung.

Sobald ein Umlaut teil der Where clausel ist, geht es gar nicht mehr.

[chs]

Zusätzlich kann man ind er ODBC-Konfig noch die Diagnose (STRDBG) starten um ggf. das Joblog zu analysieren.

Haben wir gemacht. Es ist nun klar warum das Statement nicht ausgeführt wird, unklar ist mir jedoch noch, wie ich dem entgegenwirke.

UCHAR *             0x0247AD08 [      -3] "select * from sendung where viaort1 = 'N\ffrnberg'\ 0"

Ich habe im ODBC Treiber einige Codepages variiert. Bei vielen sind die Daten bei einem Select * gar nicht mehr menschenlesbar.
Bei vielen erscheint mein 'Nürnberg' korrekt am Bildschirm.
Jedoch habe ich noch keine gefunden, bei der ich auch danach suchen kann.

Warum unterscheidet sich die Darstellung von der where clause?
Also von der AS/400 zum PC scheint korrekt übersetzt zu werden aber nicht umgekehrt.