Suchen nach Umlauten

[chs]

Falls du immer noch nicht weitergekommen bist, könntest du auch ein DB-Monitoring starten. Dort siehst du dann wie der Wert der Where-Klausel auf der Seite der DB2 aussieht, nachdem er via ODBC übertragen wurde.

Zunächstmal weiss ich natürlich nicht, wie ein DB-Monitoring zu starten ist, aber ich kann das an meinen Kunden weitergeben.

Problem ist nur, dass die DB2 ja gar keine Datei im Zugriff hat, da der Select ja gar nicht ausgeführt wird.

Wir haben das im ODBC Treiber tracen lassen und dort ist der Select schon kaputt. Nicht klar ist, ob dieser Trace vor oder nachdem Übertragen zu iSeries getraced wird.

Was ich etwas komisch finde ist, dass die Umlaute in den Feldinhalten ja korrekt angezeigt werden.

Also ein SELECT * FROM TABELLE zeigt die Umlaute. Ein INSERT oder UPDATE geht. NUR wenn der Umlaut in der WHERE CLAUSE ist, geht es nicht.
Egal bei welcher Tabelle.

Ich habe mit unserer Applikation getestet und mit einem SQL Tool. Ich bin dabei das noch mit TOAD auszuprobieren.

[andreaspr@aon.at]

Zunächstmal weiss ich natürlich nicht, wie ein DB-Monitoring zu starten ist, aber ich kann das an meinen Kunden weitergeben.

iSeries Navigator -> Datenbanken -> DB auswählen -> SQL Performance Monitors -> Rechts Klick -> Neu -> ...
Monitor-Name + Lib angeben ->
Aktueller Benutzer = der User mit dem du dich via ODBC anmelden möchtest
Jobbenutzer = QUSER?
usw.
Nach Fertig stellen, ist der Monitor automatisch gestartet -> dann machst du deine Abfrage mit dem Umlaut -> dann beendest du den Monitor -> rechts Klick auf den Monitor -> Analysieren -> Kaffee machen gehen -> rechts Klick auf SQL Statements -> Zusammenfassung -> there it is.

[BenderD]

... nochmal:
das Problem ist nicht der Inhalt der Datei und dessen Umsetzung!!!!
Das Problem ist der SQL String, der da an die Datenbank geschickt wird!!!
Habt ihr mal andere Umlaute probiert? also z.B. Rhöndorf, Gießen, Härne?

D*B

Zunächstmal weiss ich natürlich nicht, wie ein DB-Monitoring zu starten ist, aber ich kann das an meinen Kunden weitergeben.

Problem ist nur, dass die DB2 ja gar keine Datei im Zugriff hat, da der Select ja gar nicht ausgeführt wird.

Wir haben das im ODBC Treiber tracen lassen und dort ist der Select schon kaputt. Nicht klar ist, ob dieser Trace vor oder nachdem Übertragen zu iSeries getraced wird.

Was ich etwas komisch finde ist, dass die Umlaute in den Feldinhalten ja korrekt angezeigt werden.

Also ein SELECT * FROM TABELLE zeigt die Umlaute. Ein INSERT oder UPDATE geht. NUR wenn der Umlaut in der WHERE CLAUSE ist, geht es nicht.
Egal bei welcher Tabelle.

Ich habe mit unserer Applikation getestet und mit einem SQL Tool. Ich bin dabei das noch mit TOAD auszuprobieren.

[AS400.lehrling]

... nochmal:
das Problem ist nicht der Inhalt der Datei und dessen Umsetzung!!!!
Das Problem ist der SQL String, der da an die Datenbank geschickt wird!!!
Habt ihr mal andere Umlaute probiert? also z.B. Rhöndorf, Gießen, Härne?

D*B

Also mal wieder auf der Seite Windoofs.

Ein Bug im Win ODBC

kann man da nicht auch einen anderen ODBC fähige Schnitstelle verwenden - oder geht das nicht ?

Gruß AS400.lehrling

[BenderD]

... nix Windows, der Client Verhexler ODBC Treiber, oder die AS/400 Datenbank, oder auch beides hat einen Schuss.

D*B

Also mal wieder auf der Seite Windoofs.

Ein Bug im Win ODBC

kann man da nicht auch einen anderen ODBC fähige Schnitstelle verwenden - oder geht das nicht ?

Gruß AS400.lehrling

[Fuerchau]

Sieht mir ganz nach einem Fehler in der ODBC-Schnittstelle aus.
Für die ODBC-Routinen gibt es immer ein A-Version und eine W-Version.

Welche verwendet wird, hängt von einer C++-Compiler-Option ab, ob man Singlebyte oder Multibyte (UNICODE) verwendet.

Bei der Verwendung von UNICODE scheint es bei dir zu einem Umsetzungsproblem von Multibyte zu Single- oder Widecharacter zu kommen, was ggf. implizit durch den Compiler verursacht wird.

Dies macht nicht der ODBC-Treiber selber !

Die Umsetzungsroutine von Multibyte nach Singlebyte scheint nicht mit der richtigen Lokale zu arbeiten, so dass hier eben Schrott rauskommt und aus 'Nürnberg' eben 'N\ffrnberg' wird.

Versuche mal deine SQL's nicht mit TCHAR (was automatisch 1/2-Byte je nach Compiler-Option ist) sondern mit char[nn] aufzubauen.

[BenderD]

... das ist höchstens einen Teil des Problems (wenn es denn so sei). Wenn eine Applikation, welche auch immer einen String 'select * from blablabla where ort = N\ffrnberg' an den ODBC Treiber übergibt, dann hat dieser das so an die Datenbank zu senden und wenn es denn keinen Satz mit diesem Ort gibt, dann hat selbige einen SQLCODE von 100 zurückzuschicken.

D*B

Sieht mir ganz nach einem Fehler in der ODBC-Schnittstelle aus.
Für die ODBC-Routinen gibt es immer ein A-Version und eine W-Version.

Welche verwendet wird, hängt von einer C++-Compiler-Option ab, ob man Singlebyte oder Multibyte (UNICODE) verwendet.

Bei der Verwendung von UNICODE scheint es bei dir zu einem Umsetzungsproblem von Multibyte zu Single- oder Widecharacter zu kommen, was ggf. implizit durch den Compiler verursacht wird.

Dies macht nicht der ODBC-Treiber selber !

Die Umsetzungsroutine von Multibyte nach Singlebyte scheint nicht mit der richtigen Lokale zu arbeiten, so dass hier eben Schrott rauskommt und aus 'Nürnberg' eben 'N\ffrnberg' wird.

Versuche mal deine SQL's nicht mit TCHAR (was automatisch 1/2-Byte je nach Compiler-Option ist) sondern mit char[nn] aufzubauen.

[andreaspr@aon.at]

Wenn eine Applikation, welche auch immer einen String 'select * from blablabla where ort = N\ffrnberg' an den ODBC Treiber übergibt, dann hat dieser das so an die Datenbank zu senden und wenn es denn keinen Satz mit diesem Ort gibt, dann hat selbige einen SQLCODE von 100 zurückzuschicken.

D*B

Mich würde trotz allem interessieren was beim Monitoring rauskommen würde, da es geheisen hat, dass der Job "hängen geblieben ist".
Das sollte bei einem normalen SQL-Error nicht passieren. Maximal das Client-PGM darf hängen bleiben, wenn keine Exceptions abgefangen werden.

[BenderD]

... wenn die Kommunikation zwischen Treiber und Datenbank verloren geht (siehe Fehlermeldung im ersten Posting), dann ist es völlig normal, dass ein Serverjob "hängen" bleibt, selbst CPU Verbrauch kann es da geben (pollen) und je nach Timeouts bricht das dann irgendwann (900 sec. - oder je nach Einstellungen) ab.
Wenn der Client sauber programmiert ist, macht er einen disconnect und probiert es nochmal.

D*B

Mich würde trotz allem interessieren was beim Monitoring rauskommen würde, da es geheisen hat, dass der Job "hängen geblieben ist".
Das sollte bei einem normalen SQL-Error nicht passieren. Maximal das Client-PGM darf hängen bleiben, wenn keine Exceptions abgefangen werden.

[Fuerchau]

Das Problem ergibt sich ggf. aus sog. "Escape" Zeichenfolgen.
Das "\" wird als Escape gewertet und vom Treiber eben falsch interpretiert.
Es stellt sich also die Frage, warum an den Treiber die falsche Zeichenkette übergeben wird.

Das hat mit Übersetzung zwischen AS/400 und Treiber nichts zu tun sondern bewegt sich auf der Windows-Ebene.
Wie gesagt, es gibt für die Windwos-DLL's 2 Aufrufarten, entweder als char-Zeichenfolgen (A-Version) oder Unicode-Version = Wide-Character (W-Version), auch als BSTR bekannt.
Irgendwo da gibts ein Umsetzungsproblem, wie wohl der SQL-Trace aufzeigt.

[chs]

Liebe Unterstützer!
Zunächst meinen herzlichsten Dank an alle die so eifrig mitgedacht und unterstützt haben.
So viele schnelle und qualifizierte Antworten habe ich in keinem Forum bekommen.

Das Problem wurde nun auf der AS/400 Seite gelöst. Ich bin weit davon entfernt zu verstehen, was da genau gemacht wurde. Vielleicht kann der eine oder andere aber damit etwas anfangen.

Vielen Dank nochmal an Alle!

This morning my colleague finally found out what the problem was causing the Iserie system to get into a loop for special characters like ü . It was related to a security tool Robot/Security are using to secure are system. This tool starts jobs when a Iserie server is started for an ODBC connection

Below actions was taken to solve the problem
For an number of servers an RSE (Robot/Security) program was defined as exit program, this was also setup for the “Database Server – entry” (QIBM_QZDA_INIT).

When an SQL statement makes a where selection with the Umlaut (when CPU use goes up) a number of RSE programs are on top in the program stack of the related job QZDASOINIT.

All defined RSE exit programs for exit point are removed. The prestart jobs QZDASOINIT are stopped and restarted..

We can conclude that the problem was not caused by a wrong code page or the ODBC driver.

Thanks for all the support you gave me last week to solve this issue. The cause of this problem was also a complete mystery to me.

[BenderD]

... typischer Fall von "Eier selber auf die Schienen genagelt" ...