Umlaute in iSeries Access

[oschmac]

Hallo,

ich habe eine .Net Anwendung geschrieben, die zum einen per CWBX Programme auf dem System i aufruft und zum anderen per IDb2-Treiber Daten holt und schreibt. Die Software ist auf mehreren Rechnern installiert. Ich habe nun das Problem, dass auf einem Rechner alles wunderbar funktioniert, aber auf einem anderen Rechner die Umlaute falsch dargestellt / übertragen werden. Auf dem Host läuft V5R4, die iSeries Access-Version ist V5R8. CCSID auf dem Host ist 273, LANGID ist DEU. Alle Clientjobs (QZRCSRVS und QZDASOINIT) laufen ebenfalls mit CCSID 273 und LANGID DEU. Dennoch kommt es bei mehreren Rechnern vor, dass sowohl bei Programmaufrufen, als auch bei DB-Zugriffen die Umlaute falsch konvertiert werden. Sie werden auf dem PC korrekt angezeigt, in der DB/2 aber falsch gespeichert. Auf anderen Rechnern funktioniert die Konvertierung reibungslos.
Ich bin mit meinem Latein so ziemlich am Ende, da ich nicht weiß, an welchen Schrauben ich hier noch drehen kann.

Gruß
Olaf

[Fuerchau]

Stimmt denn auf dem "falschen" Rechner die Sprachumgebung des Windows ?

Ansonsten solltest du die Aufrufe per CWBX auf jeden Fall durch SQL-Call's (Storedprocedures) ersetzen.
Stored Procedures können auch externe Programme aufrufen, im Zweifel auch per "CALL QSYS.QCMDEXC(?, ?)".

[oschmac]

Es handelt sich um ein deutsches Windows mit deutschen Einstellungen. Der Unterschied ziwschen den funktionierenden und fehlerhaften Installationen liegt am System i, mit dem iSeriesAccess installiert wurde, sprich: Die fehlerhaften Rechner wurden installiert mit einer Verbindung zum aktuellen System i, die funktionierenden Rechner wurden mit einer Verbindung zu einem anderen System i installiert. Kann es irgendetwas damit zu tun haben? Kann der INZPCS eine Rolle spielen?
Ich habe das Problem der Konvertierung sowohl bei SQL (inkl. Stored Procedures) als auch bei CWBX. Ich habe nur die Erfahrung gemacht, dass der Overhead bei SP höher und somit das Antwortverhalten schlechter ist als bei COM-Aufrufen.

Gruß
Olaf

[Fuerchau]

Wenn dir der Overhead von ein paar Microsekunden relevant erscheint...

Allerdings ist der Aufwand, eine SP aufzurufen erheblich geringer als per CWBX einen RemoteCommandCall abzusetzen.
Ausserdem erfolgt der Aufruf in einem ganz anderen Job.
Per SP kannst du auch Resultsets zurückgeben, per CWBX nur Strukturen die du mit zusätzlichen API-Aufrufen bedienen musst.

Was deinen Zeichensatz angeht, so kann ich mir das eigentlich nicht erklären.
An irgendeiner Stelle scheinst du eine CCSID falsch anzugeben bzw. es schlagen irgendwelche Defaults zu.

Wichtig ist folgendes:
Die Datei und das System müssen eine CCSID <> 65535 haben!
Ggf. sollte der Anmeldeuser im USRPF eine CCSID <> 65535 haben!

Hast du in deiner ODBC-Konfig das Häkchen für CCSID-65535-Umsetzung setzen müssen ?
Wenn ja, haben deine Dateien keine CCSID und es kommt genau zu diesen Effekten. Irgendwo gibts halt einen Unterschied.

[oschmac]

QCCSID ist 65535. Ich habe dem aber keine Bedeutung beigemessen, da es ja wie beschrieben von einigen PC aus korrekt funktioniert. Alle Rechner melden sich mit demselben Benutzerprofil an. Insofern dürfte es eigentlich keine Probleme geben. Die Jobs verwenden alle CCSID 273.
Meinses Wissen benutzt der .NET DataProvider nicht die ODBC-Konfiguration. Es sind auch keine ODBC Datenquellen für iSeries Access installiert.
Ich denke auch, dass irgendwo auf den PC ein Defaultwert Probleme macht. Ich weiß halt nur nicht, wo ich suchen soll.

Für den Programmzugriff per COM habe ich mir eine Klasse erstellt, die aus einer beliebigen Klasse unter Verwendung von Benutzerattributen und Reflection Datenstrukturen für Programmaufrufe erzeugt. Nach dem Call werden die Datenstrukturen wieder aufgelöst und den Eigenschaften der ursprünglichen Klasse zugeordnet. Da wir Programme immer mit Datenstrukturen als Parameter aufrufen besteht der Aufwand nur noch in der Definition der Parameterklasse.
Mit SP habe ich das Problem, dass ich in der Definition der Externen Prozedur auf dem Host die Bibliothek des aufzurufenden Programmes angeben muss. Da wir mit variablen Bibliothekslisten arbeiten, die zur Laufzeit wechseln können, bin ich gezwungen die SP bei jedem Programmaufruf neu zu erstellen und anschließend wieder zu entfernen. Das kostet einfach viel Zeit. Es mag sein, dass es mit OLE/DB-Treibern einfacher geht, aber wie gesagt, wir verwenden den .NET Dataprovider und der bietet leider für Programmaufrufe nicht den gewünschten Komfort.

Gruß
Olaf

[Fuerchau]

Das hat auch gar nichts mit der ODBC-Funktionalität zu tun sondern mit dem CCSID-Handling dass in allen Treibern (ODBC, JDBC, OLEDB und .NET) gelöst werden muss.

Wie sieht der Connection-String aus ?

Prüfe mal, wie die CCSID des Server-Job's des falsch laufenden Users steht.

Und was deine Lösung angeht, jedem halt das seine. SP's sind auf jeden Fall effektiver.
Ausserdem läßt sich jede SP als externe SP (also Programmaufruf) deklarieren und für jede Lib registrieren.

Man hat dann auch ggf. weniger Probleme mit den CCSID's, da du diese ja bei CWBX selber verwalten musst.

[oschmac]

Ich habe die letzten Tage zur tiefergehenden Analyse genutzt. Es ist ja so, dass die Zeichenkonvertierung bereits auf dem PC stattfindet. Ich nutze dazu die StingConverterClass. Bezüglich des Systems zeigen beide PCs die Hostcodepage 273 an und geben in der cwbnlHostCodePageEnum den Wert 1 (cwbnlCodePageAS400) zurück. Dennoch konvertieren einige Rechner z.B. ein ö nach 204 statt wie gewünscht 106. 204 passt zur CCSID 500, die ja verwendet würde, wenn zum Zeitpunkt der Konvertierung keine Verbindung zum Host bestünde. Das kann ich aber ausschließen. Die Verbindung steht.
Meine Frage: Wo finde ich auf dem PC die Codepages anhand derer die Zeichenkonvertierungen vorgenommen werden, bzw. wo kann hinterlegt werden, welche Codepages wann Verwendung finden?

[Fuerchau]

Ich denke mal, die Defaulteinstellung für CodePage des StringConverters ist 500, wenn keine Verbindung besteht.
Du kannst diese Eigenschaft aber selber gezielt auf 273/1141 setzten oder dafür sorgen, dass du zuerst für eine Verbindung sorgst oder das CodePageConverter-Objekt verwendest.

Aber wie schon mal gesagt, als SQL-Prozedur wäre das viel einfacher.