Suchen nach Umlauten

[chs]

Wir programmieren unter Windows mittels Visual C++ 6er Studio und greifen via ODBC Treiber auf die DB2 Datenbank einer iSeries zu.

Ein großer Teil der Datenbankzugriffe scheint problemlos zu funktionieren. Inserts, Updates, Selects alles kein Problem. Bis in der Where-Clause des Selects ein Umlaut vorkommt.

Das Symptom auf Windowsseite: Es kommt einfach keine Antwort zurück. Auch bei winzig kleinen Tabellen wartet man >10 min.
Das Symptom auf der AS/400: Prozessorlast steigt auf 50% an. Man kann den Job nur killen.

Anschließend sieht man im Trace (wir schreiben Select und Antwort immer weg):

 ErrorMessage:     SQL call failed.
  ErrorCode:        5
  VendorError1:     8405
  VendorError2:     1
    
  VendorMessage1:   08S01
  VendorMessage2:   [IBM][System i Access ODBC Driver]Communication link failure. comm rc=8405 - CWBCO1047 
    ->- The System i server application  disconnected the connection
 Sql-Error: 25.03. 10:36:00:406: SELECT DISTINCT ORTE.LAND, ORTE.POSTLEITZAHL, ORTE.ORTSNAME, ORTE.GTB_NR,
   -> ORTE.GEBIETS_NR, ORTE.X_KOORDINATE, ORTE.Y_KOORDINATE, ORTE.ORTSKLASSE_BSL, ORTE.ORTSKLASSE_DEGT, ORTE.BHFSTUECKGUT,
   -> ORTE.GEMSCHLUESSEL, ORTE.ORTSNUMMER, ORTE.ORT, ORTE.ORTSTEIL, ORTE.KENNZEICHEN, ORTE.ORTSNAME_NORM, 
   ->ORTE.ORTSTEIL_NORM, ORTE.ORT_NORM, ORTE.ROLLGELD_BSL, ORTE.GEM_SCHLUESSEL_LAND, ORTE.GEM_SCHLUESSEL_BEZIRK,
   -> ORTE.GEM_SCHLUESSEL_KREIS, ORTE.GEM_SCHLUESSEL_GEMEINDE, ORTE.SATZKENNUNG, ORTE.ORTSGROESSE, ORTE.MATRIX_INDEX,
   -> ORTE.BREITENGRAD, ORTE.LAENGENGRAD, ORTE.MANUELL_KZ, ORTE.ORTSTYP FROM ORTE WHERE LAND = 'DE' AND ORT 
   ->= 'Nü' ORDER BY LAND, POSTLEITZAHL, ORT

Wobei, der Disconnect erst durch das Abbrechen des Jobs kommt. Vorher passiert gar nichts.

Interessanterweise, diese Umlaute sind mittels der Applikation erfasst worden und immer noch lesbar. Nur im Select selbst (where) taucht das Problem auf.

Als ODBC Treiber wurde der iSeries ACCESS Treiber verwendet.
Das Problem ist auf unsere DB2 Windowsdatenbank nicht nachvollziehbar.

Jemand eine Idee?

[andreaspr@aon.at]

hast du schon versucht den kompletten sql-command auf der as/400 auszuführen?

verwendet ihr in c++ parameter-objekten oder bastelt ihr euch die sqls komlett selbst zusammen?

lg andreas

[TARASIK]

Hallo,
welches Release ist denn auf der ISeries installiert und welches Servicepack des ISeries Access ist denn auf dem PC installiert ?

[Fuerchau]

Welche CCSID hat die DB ?
Welche CCSID hat der User ?
Wird ggf. Unicode verwendet (WCHAR) ?

Wenn die DB CCSID 65535 hat, steht dann in der ODBC-Konfig der Haken bei "65535 umsetzen" ?

Die Frage ist eben, kommt das 'Nü' auch so auf der AS/400 an, denn was du protokollierst kann anders aussehen.

Kannst du diesen SQL über den OpsNav testen ?

[chs]

Hallo,
welches Release ist denn auf der ISeries installiert und welches Servicepack des ISeries Access ist denn auf dem PC installiert ?

iSeries: 5.3
iSeries Access: V6R1M0

Ich hoffe das ist aussagekräftig?

[Fuerchau]

Das könnte ein Kompatibilitätsproblem sein, dass CA V6R1M0 nicht mit V5R3 zurechtkommt.

Trotzdem nochmal:
a) Probiere einen ähnlichen SQL mit dem OpsNav oder mal mit MS-Query (über Excel) aus.

b) Ersetze die Konstanten im SQL mit "?" und verwende Parameter-Objekte

[chs]

Das könnte ein Kompatibilitätsproblem sein, dass CA V6R1M0 nicht mit V5R3 zurechtkommt.

Trotzdem nochmal:
a) Probiere einen ähnlichen SQL mit dem OpsNav oder mal mit MS-Query (über Excel) aus.

b) Ersetze die Konstanten im SQL mit "?" und verwende Parameter-Objekte

Man ihr seid aber schnell hier im Forum. Ich komme ja kaum nach meinen Kunden zu fragen.

Wenn wir den Select direkt auf der AS/400 absetzen, funktioniert er. Das ist schonmal eine wichtige Erkenntnis.

Die DB steht wohl mit CCSID auf 65535. Ich habe im ODBC Treiber den Haken gesetzt unter Tab Conversions:

Convert binary data (CCSID 65535) to text

War das der richtige Haken?

Jedenfalls brachte es keine Veränderung. Ohne Umlaut wird der Select ausgeführt. Mit Umlaut bekommt die AS/400 die Krise.

OPSNAV kennt mein Kunde nicht.
Den Select haben wir auch schon in SQL Tool ausgeführt (also ohne unsere Applikation): Gleiches Verhalten.

Den Part mit den ? verstehe ich nicht.

[chs]

So sieht der Treiber derzeit aus.

[Fuerchau]

Das schein eher ein Problem des V6R1-ODBC's zu sein.
Mit V5 hatte ich da nie Probleme.
Allerdings verwende ich bei SQL's per ODBC GRUNDSÄTZLICH Parametermarker.

CCSID 65535 gibt immer ein Problem, da der ODBC-Serverjob immer mit einer korrekten CCSID gestartet wird.

Sonderzeichen (wie Umlaute) können ggf. nicht korrekt umgesetzt werden.

Vielleicht hilft dir noch folgende ODBC-Einstellung (ODBC-Konfig):
Register "Umsetzung"->Erweitert->CCSID für SQL-Anweisung->CCSID für Unicode (UCS-2)

Wenn das auch nicht hilft, ggf. CA für V5R3/V5R4 incl. Service-Pack installieren.

[andreaspr@aon.at]

was die parameter betrifft gibt es hier einen netten link der dir für die zukunft helfen könnt.
myCSharp.de - DIE C# und .NET Community | Artikel | [Artikelserie] Parameter von SQL Befehlen

nur als info: ich hab CA V5R4 am PC installiert und kann via ODBC sowohl mit einer AS/400 V5R4 als auch V5R3 mit umlauten arbeiten.

[chs]

was die parameter betrifft gibt es hier einen netten link der dir für die zukunft helfen könnt.
myCSharp.de - DIE C# und .NET Community | Artikel | [Artikelserie] Parameter von SQL Befehlen

nur als info: ich hab CA V5R4 am PC installiert und kann via ODBC sowohl mit einer AS/400 V5R4 als auch V5R3 mit umlauten arbeiten.

Im Quellcode der Applikation tun wir das natürlich, aber was hat das mit dem Select zu tun.

Der Select, wie er abgesetzt wird, ist reines SQL, wie man ihn eintippen würde.

[chs]

Auf der iSeries, auf der die DB läuft ist Folgendes eingestellt:

Language ID= ENU
Codepage=37

Ist das irgendwie relevant?