CCSID und ODBC

[HJS]

Hallo Forum!

Folgende Situation (V5R2):

Tabelle und Feld: CCSID 273

Nun haben wir viele User (z.B. aus Tschechien) mit folgenden Einstellungen:
Sprachen-ID: CSY
Landes- oder Regions-ID: CZ
Zeichensatz-ID: 870

Wenn ein solcher User mit der 5250-Anzeigeemulation und eingestellter Host-Codepage 870 z.B. über STRSQL auf das Feld zugreift, wird alles richtig angezeigt.

Ich will nun aber die Daten per ODBC auf den PC holen und schaffe nur teilweise richtige (und damit falsche) Lösungen:

Probleme bereiten weniger deren Sonderzeichen, sondern "unsere" Umlaute, die ebenfalls (vor allem im Ungarischen) Anwendung finden.

Eine "normale" Abfrage mit SELECT Feld FROM ... liefert zwar richtige Umlaute, aber falsche Sonderzeichen.

Die Lösung (die ich übrigens hier entdeckt habe) mit
SELECT CAST(CAST Feld AS CHAR(50) FOR BIT DATA) AS CHAR(50) CCSID 870) AS Feld FROM ...
ergibt richtige Sonderzeichen aber statt der Umlaute stehen {, }, \, [, ] und | (was irgendwie auch richtig ist, wenn man sich die beiden Codepages 273 und 870 ansieht).
Ich hätte allerdings erwartet, dass die Umlaute, wenn sie ein User mit obigen Einstellungen eingibt, in der Datei falsch stehen (also mit Klammern usw.). Weil dem nicht so ist, funktioniert das mit dem CASTen auch nicht richtig.

Ich kann die Datei aber auch nicht auf mehrere Dateien aufteilen, weil die ERP-Software damit problemlos arbeitet und ich die Daten "nur" auslesen will.

Wie kann ich den ODBC-Treiber dazu überreden, sich wie die 5250-Anmeldeemulation zu verhalten?

Ich habe leider keine Einstellung gefunden. Es hilft nichts bei der Verbindung mit einem solchen User zuzugreifen. Der springende Punkt scheint die Einstellung der Host-Codepage bei der Emulation zu sein.

- Hans J. Sieghart

[RaMai]

Hallo Forum!

Folgende Situation (V5R2):

Tabelle und Feld: CCSID 273

Nun haben wir viele User (z.B. aus Tschechien) mit folgenden Einstellungen:
Sprachen-ID: CSY
Landes- oder Regions-ID: CZ
Zeichensatz-ID: 870

Wenn ein solcher User mit der 5250-Anzeigeemulation und eingestellter Host-Codepage 870 z.B. über STRSQL auf das Feld zugreift, wird alles richtig angezeigt.

Ich will nun aber die Daten per ODBC auf den PC holen und schaffe nur teilweise richtige (und damit falsche) Lösungen:

Probleme bereiten weniger deren Sonderzeichen, sondern "unsere" Umlaute, die ebenfalls (vor allem im Ungarischen) Anwendung finden.

Eine "normale" Abfrage mit SELECT Feld FROM ... liefert zwar richtige Umlaute, aber falsche Sonderzeichen.

Die Lösung (die ich übrigens hier entdeckt habe) mit
SELECT CAST(CAST Feld AS CHAR(50) FOR BIT DATA) AS CHAR(50) CCSID 870) AS Feld FROM ...
ergibt richtige Sonderzeichen aber statt der Umlaute stehen {, }, \, [, ] und | (was irgendwie auch richtig ist, wenn man sich die beiden Codepages 273 und 870 ansieht).
Ich hätte allerdings erwartet, dass die Umlaute, wenn sie ein User mit obigen Einstellungen eingibt, in der Datei falsch stehen (also mit Klammern usw.). Weil dem nicht so ist, funktioniert das mit dem CASTen auch nicht richtig.

Ich kann die Datei aber auch nicht auf mehrere Dateien aufteilen, weil die ERP-Software damit problemlos arbeitet und ich die Daten "nur" auslesen will.

Wie kann ich den ODBC-Treiber dazu überreden, sich wie die 5250-Anmeldeemulation zu verhalten?

Ich habe leider keine Einstellung gefunden. Es hilft nichts bei der Verbindung mit einem solchen User zuzugreifen. Der springende Punkt scheint die Einstellung der Host-Codepage bei der Emulation zu sein.

- Hans J. Sieghart

Wir hatten dieses Problem auch, in userem Fall CCSID 037 englisch und es ging um dänische Zeichen.
Damit alles richtig umgesetzt wird muß die CCSID auch bei den tschechischen Usern auf 273 gesetzt werden und nur das Tastaturlayout in CZ. Dann werden die zeichen auch richtig gespeichert.
Hope that helps....

[HJS]

Wir hatten dieses Problem auch, in userem Fall CCSID 037 englisch und es ging um dänische Zeichen.
Damit alles richtig umgesetzt wird muß die CCSID auch bei den tschechischen Usern auf 273 gesetzt werden und nur das Tastaturlayout in CZ. Dann werden die zeichen auch richtig gespeichert.
Hope that helps....

Das scheint mir leider nicht so einfach bei >200 Usern. Das System ist auch schon seit über 2 Jahren so im Betrieb. Da ist schon eine kleine Datenmenge zusammengekommen. Und ansonsten funktioniert es ja auch klaglos (Formulare, Ausdrucke alles richtig). Im Sinne von "never touch a running system" suche ich eher nach einem Workaround mit SQL und ODBC. Trotzdem danke für deinen Hinweis.