View Full Version : Tschechischen Zeichensatz in Excel exportieren mit ClientAccess Datenübertragung
Hallo Forum,
Ich habe ein Thema welches schon viele Male hier im Forum diskutiert wurde
aber immer wieder zu Problemen führt.
Nun zu meinem spezifischen Problem.
Wir betreiben eine AS400 resp. i5 Server mit folgenden wichtigen Angaben
Release: V5R3M0 (ich weiss sehr alt)
Zeichensatz-ID: 697
Code Page - CCSID: 500
Unser Werk in Tschechien arbeitet mit Client Access und Host-Codepage 870=Tschechien
und die User sind im Profile mit LANGID=CSY, CNTRYID=CZ und CCSID=870 eingestellt.
So weit so gut, denn die tschechischen Zeichen werden so korrekt dargestellt.
Nun möchten wir mit dem Datenübertragungsprogramm von Client Access die Daten in ein Excelfile sowie in ein .txt file übertragen und da fangen die Probleme an, denn die tschechischen Zeichen werden falsch dargestellt in Excel oder .txt. Ich habe schon einiges versucht ohne Erfolg. z.B.
- Einstellungen in PC-Datei
- Gleiche Einstellung in Client Access und User
- Einstellung -> Übertragung und eigne Umsetztabellen
Nun bin ich etwas ratlos - Wer hat da einen Tipp ?
KingofKning
03-09-18, 14:19
Die Frage wäre was ist Dein Zielsystem? Win10 oder Win7 oder was?
Hast Du mal versucht die Daten per ODBC direkt in Excel zu lesen?
Funktioniert es nur bei Dir in Deutschland nicht oder auch nicht drüben in Tschechien bei einem Tschechien Windows (falls vorhanden)
GG 4289
Hallo KingofKning
Das Zielsystem ist Win7
und ich befinde mich in der schönen Schweiz :)
Per ODBC direkt in das Excel funktioniert es auch nicht - leider....
In Tschechien müsste wir das noch probieren, resp. wir setzen hier ein tschechischen Laptop auf.
Ergänzende Frage:
Da das System ja wohl mit CCSID 500 (westeuropa International) eingestellt ist, nimmt SQL eben an, dass die Daten nicht 870 sind sondern 500.
Korrekt wäre es gewesen, auch das System in 870 aufzusetzen und alle Datenbankdateien in 870 zu erstellen.
Jetzt habt ihr den Salat.
Aber es könnte eine Lösung geben, ich weiß nur nicht, ob V5R3 bereits die CCSID 13488 (UCS2) untersützt und alle benötigten PTF's dafür installiert sind.
Dann kannst du auf dem V5R3 Views erstellen, die die Daten dann korrekt umcasten:
select cast( cast( cast(Name as char(nn) ccsid 65535) as char(nn) ccsid 870) as graphic(nn) ccsid 13488)
from myfile
Wie schon oft beschrieben. Ein Cast von/nach 65535 ist binär und setzt keine Zeichen um.
Somit setzt der rote Cast die 500er-Daten in binär um.
Anschließend setzt der blaue cast in 870 um. In diesen beiden Fällen erfolgt jedoch keine Codewandlung.
Erst der türkise Cast erfordert eine Umsetzung in UCS2 => Unicode.
Diese View kann man dann in Excel direkt per ODBC importieren, denn Excel kann Unicode.
nn = die benötogte Feldlänge.
Ergänzende Frage:
Da das System ja wohl mit CCSID 500 (westeuropa International) eingestellt ist, nimmt SQL eben an, dass die Daten nicht 870 sind sondern 500.
Korrekt wäre es gewesen, auch das System in 870 aufzusetzen und alle Datenbankdateien in 870 zu erstellen.
Jetzt habt ihr den Salat.
Aber es könnte eine Lösung geben, ich weiß nur nicht, ob V5R3 bereits die CCSID 13488 (UCS2) untersützt und alle benötigten PTF's dafür installiert sind.
Dann kannst du auf dem V5R3 Views erstellen, die die Daten dann korrekt umcasten:
select cast( cast( cast(Name as char(nn) ccsid 65535) as char(nn) ccsid 870) as graphic(nn) ccsid 13488)
from myfile
Wie schon oft beschrieben. Ein Cast von/nach 65535 ist binär und setzt keine Zeichen um.
Somit setzt der rote Cast die 500er-Daten in binär um.
Anschließend setzt der blaue cast in 870 um. In diesen beiden Fällen erfolgt jedoch keine Codewandlung.
Erst der türkise Cast erfordert eine Umsetzung in UCS2 => Unicode.
Diese View kann man dann in Excel direkt per ODBC importieren, denn Excel kann Unicode.
nn = die benötogte Feldlänge.
Hallo,
das ist doch mal ein cooles Ding :-)
Vielleicht geht ja auch nvarchar
gruß an alle
N-Typen sind erst mit V7 (ggf. V6 + TRx) eingeführt worden, dann geht das natürlich ebenso.
Allerdings wirst du zum Thema 3-fach-Cast hier im Forum schon ziemlich viele alte Beträge von D*B und mir finden.
Hallo Fuerchau,
Da wir dieses System für ganz Westeuropa nutzen (diverse Firmen)
ist es schon richtig aufgesetzt mit 500 und nicht 870.
Auf jeden Fall besten Dank für Deine Erklärungen.
Mit diesem umcasten funktioniert es auch nicht und das liegt wohl am Uralt V5R3.
Wir haben jetzt ein Weg gefunden (Excel-sei-Dank) und können die Zeichen umsetzen.
Da wir diese Umsetzung nur für eine Migration benötigen, können wir damit leben
So wie ich das verstanden habe, habt ihr doch für jedes Land eine eigene AS/400?
Oder, wie es ebenso vernünftig gewesen wäre, je Landesgruppe eine eigene Daten-Lib mit der korrekten CCSID sowie passendem Job, Bildschirm und Drucker.
Die CCSID 500 gilt eben nur für geografisches Westeuropa und nicht für Osteuropa, so wie es in der Beschreibung steht.
870 ist eben speziell für Osteuropa und nicht mit 500 kompatibel.
Läuft das umcasten denn auf einen Fehler und wenn ja auf welchen?
Nein wir haben nicht für jedes Land eine eigene AS/400 sondern für ganz Europa nur eines
und dazu gehört auch unser Werk in Tschechien. Ja für Tschechien haben wir eine eigene
Daten-Lib aber die steht auch auf 500 (korrekt wäre sicher 870).
Da wir jetzt das Werk migrieren nach SAP und welches nicht auf AS/400 läuft, leider :(
werden wir nichts mehr ändern.
Nein das umcasten läuft nicht auf Fehler.
Da wir ganze Files mit allen Feldern migrieren,
wüsste ich jetzt nicht so gleich auf die Schnelle
wie das mit dem umcasten gehen würde.
Auf jeden Fall es hat sich erledigt und ich bin Froh dass es dieses Forum gibt - Macht weiter so !
Danke für die Antwort.
Allerdings würde mich deine Excel-Lösung ohne CCSID-Umsetzung interessieren.
Dies wäre bestimmt auch eine Hilfe für andere User.
Könntest du uns diese noch nahebringen?