PDA

View Full Version : Suchen nach Umlauten



Seiten : 1 2 [3] 4 5 6

andreaspr@aon.at
29-03-10, 12:35
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!

chs
29-03-10, 12:42
Dann probier doch folgendes:

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

wobei nn die originale Feldlänge ist.

Worin besteht der Unterschied zu meinem Select? Vielleicht sehe ich es nur nicht:

Ja - das habe ich wie folgt probiert:


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

chs
29-03-10, 12:53
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
29-03-10, 13:02
job-ccsid auf der as/400??

Fuerchau
29-03-10, 13:19
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.

BenderD
29-03-10, 13:19
... der CAST von dem Feld ändert den Wahrheitsgehalt des Statements nicht, sondern nur die Ergebnismenge, die dann von leer auf Inhalt wechseln könnte.
Für mich sieht das eher so aus, dass der SQL String von legal nach illegal wechselt, so von der Art wenn ich
"select * from irgendwas where name =" + Name
gegen die Datenbank schicke und in Name dann O'Hara drin steht.
Deswegen war der Ansatz mit dem prepared Statement erst mal richtig.

D*B

Dann probier doch folgendes:

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

wobei nn die originale Feldlänge ist.

chs
29-03-10, 13:26
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
29-03-10, 13:40
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.

OK. Bei den 5250 Sitzungen wird 037 als Codepage verwendet.

chs
29-03-10, 13:44
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.

Fuerchau
29-03-10, 13:57
Dann gäb's zumindest einen SQL-Fehler und keinen Hänger.