Suchen nach Umlauten

[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.

[BenderD]

... 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]

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]

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]

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]

Dann gäb's zumindest einen SQL-Fehler und keinen Hänger.

[Fuerchau]

Die Codepages kannst du getrost vergessen, da 037 (USA-Englisch) zwischen 5250 und Datenbank ja korrekt passt, selbst wenn die DB 65535 hat.

Du kannst allerdings auch die DB-CCSID auf 037 per CHGPF ändern, dann sollte es eigentlich gehen.

Wichtig ist da nun eher, deinen SQL zu berichtigen.
Irgendwie wird wohl den 'Nürnberg' in 'N\ffrnberg' übersetzt. Wobei "\ff" eigentlich Hex(FF) gemeint ist und das wirst du nie finden (oder ist das nur eine Anzeige im Debugger ?).

Auch wegen Dieters Hinweis emfehle ich dringend Parametermarker!!!

Desweiteren:
Hast du für dein C++-Programm UNICODE definiert ?
Dann musst du auch über die ODBC-Konfig den SQL-String als Unicode verwenden.

Verwendest du ADO-Objekte oder native SQL-Routinen (SQLExecute, SQLConnect, CLI) ?

Wenn Du mit Parametermarkern arbeitest, kannst du den Parametertyp dann auch auf WCHAR setzen.

Ansonsten musst du in deinem Programm den SQL-String auf char[xx] anpassen und die Werte in Singlebyte konvertieren (Makro W2A).
Besser ist jedoch die Verwendung der ADO-Klassen.

[andreaspr@aon.at]

hast du schon probiert das gleiche phänomen auch bei anderen tabellen und unterschiedlicher CCSID auftritt?
zumindest testhalber würde ich das auch mit parameter probieren, denn diese sollten die konvertierungen automatisch vornehmen!

[chs]

hast du schon probiert das gleiche phänomen auch bei anderen tabellen und unterschiedlicher CCSID auftritt?
zumindest testhalber würde ich das auch mit parameter probieren, denn diese sollten die konvertierungen automatisch vornehmen!

Ist mit Parametern das 'Casting' gemeint?
Das habe ich schon probiert.
Aber nochmal, nicht dass wir uns misverstehen.
Ich tippe den Select per Hand in eine ODBC SQL Tool ein.

Ich verwende also zum Testen keine C++ Programmierung.

[andreaspr@aon.at]

nein, mit parametern ist was ganz anderes gemeint. schau dir mal den link den ich anfangs gepostet hab genauer an.
zuerst dein sql-string:
tab = "select * from tab where sp1 = ?"
und dann ein parameterobjekt, welches für das "?" eingesetzt wird.
das machst du aber nur in einem selbst programmierten programm (c++, c#, ...)

das heißt du verwendest also ein nicht selbst geschriebenes pgm um dein select abzusetzen? wenn ja, wie heist dieses pgm?

[Fuerchau]

Ich habe das jetzt mit V5R4 und einer Tabelle mit CCSID 65535 ausprobiert.
Beim Select gibt es absolut keine Probleme, die Daten werden korrekt gefunden und angezeigt.

Es gibt aber ein CCSID-Problem.

Ich denke, du hast keine andere Chance als
a) die CCSID der PF zu korrigieren
oder
b) eine View mit Casting auf die korrekte CCSID anzulegen

[BenderD]

... die CCSID der Tabelle ist da m.E. Banane, wenn da was faul ist, werden keine Sätze (oder die falschen gefunden). Dieses Problem hier muss auf der Strecke Frontend Treiber CCSID des Database Dämons liegen - und zusätzlich muss da auch noch ein Bug/Inkompatibilität im Spiel sein; entweder sollte da ein SQL Code zurückkommen (Statement wird invalid) oder eben SQL Code 100 (nix gefunne).

D*B

Ich habe das jetzt mit V5R4 und einer Tabelle mit CCSID 65535 ausprobiert.
Beim Select gibt es absolut keine Probleme, die Daten werden korrekt gefunden und angezeigt.

Es gibt aber ein CCSID-Problem.

Ich denke, du hast keine andere Chance als
a) die CCSID der PF zu korrigieren
oder
b) eine View mit Casting auf die korrekte CCSID anzulegen