Umlaute in iSeries Access

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