Umlaute in iSeries Access

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