[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Apr 2002
    Beiträge
    32

    Question 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 ?

  2. #2
    Registriert seit
    Aug 2006
    Beiträge
    2.072
    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

  3. #3
    Registriert seit
    Apr 2002
    Beiträge
    32
    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.

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    Jan 2001
    Beiträge
    832
    Zitat Zitat von Fuerchau Beitrag anzeigen
    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

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Apr 2002
    Beiträge
    32
    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

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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?
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  9. #9
    Registriert seit
    Apr 2002
    Beiträge
    32
    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 !

  10. #10
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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?
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  11. #11
    Registriert seit
    Apr 2002
    Beiträge
    32
    Da Excel bei uns unter UNICODE (UTF-8) läuft,
    haben wir im Excel eine ganz einfache Umwandlung durchgeführt
    mit dem Befehl "Ersetzen". Wir haben einfach ein Makro erstellt
    mit allen gängigen tschechischen Umlauten wie wir sie von der AS/400 bekommen haben
    und dann durch den richtigen UNICODE (Replacement=ChrW(345)) ersetzt für jedes Zeichen.

    Beispiel:
    Cells.Replace What:="ð", Replacement:=ChrW(345), LookAt:=xlPart, SearchOrder _
    :=xlByRows, MatchCase:=True, SearchFormat:=False, ReplaceFormat:=False

    Das könnte natürlich noch viel einfacher und komfortabler umgesetzt werden,
    indem eine 2. Tabelle mit allen Übersetzung der tschechischen Zeichen in das richtig UNICODE Zeichen erstellt wird, und dann mit einem Makro mit einer Schlaufe diese Tabelle abgearbeitet wird.

  12. #12
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Excel läuft nie unter UTF-8 (1-4-Zeichen) sondern immer mit Unicode (WideChar = 16-Bit), dies entspricht dem UCS2 der AS/400. UTF-8 dient ausschließlich als Austauschformat.
    WideChar wurde von Microsoft mit Windows98/2000 eingeführt.
    Während VB6/VBA.6 bereits WideChar als default hatte, arbeitete VB5 und VBA.5 noch mit Char.

    Zu erkennen ist das an der Funktion ChrW(), dies ist die WideChar-Funktion zu Chr() 8-Bit.
    Das Gegenstück dazu ist AscW() statt Asc() um den Unicodewert auszulesen.
    Und noch zusätzlich gibt es die Unterscheidung zwischen Len() = Zeichenlänge und LenB() = ByteLänge.

    Entschuldigung für die Korrektur;-).

    Eleganter könnte man das sicherlich über ein VBA-AddIn steuern, dem man in einer Tabelle die Quell- und Zielzeichen hinterlegt.
    Beim Start des AddIns wird dies in eine 16-Bit-Tabelle geladen, die für alle Codes eine 1:1-Übersetzung speichert und an Hand der Vorgabetabelle die Ausnahmen dazu lädt.
    Es gibt dann eine Funktion, der man dann den Zellwert übergibt und den Ersatzwert zurückgibt.
    Das Bilden des Ersatzwertes erfolgt einfach über eine Schleife mit den Funktionen AscW() als relativer Index der gespeicherten Tabelle für die Funktion ChrW().

    Beispiel:
    dim Ersatz(0 to 32767) as integer 'zu befüllende Tabelle beim Init

    public function ErsatzString(byval FromString as string) as string
    dim xI as integer
    ErsatzString = FromString
    for xI = 1 to len(ErsatzString)
    mid$(ErsatzString, xI, 1) = ChrW(Ersatz( AscW(Mid$(ErsatzString, xI, 1))))
    next
    end function

    Der Vorteil ist auf jeden Fall die erhebliche Einsparung der Laufzeit, da hier keine Suchfunktionen durchgeführt werden.
    Die Replacefunktion scannt nach dem Code, ersetzt alle Vorkommen und erstellt einen neuen Zellwert.
    Dies erfolgt je Zelle und Code!
    Die VBA-Funktion erstellt nur 1 neuen Zellwert und ersetzt alle Zeichen auf einmal.
    Viel Spaß beim Probieren, aber ich glaube es lohnt sich.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Similar Threads

  1. QSH und Zeichensatz
    By Curious in forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 06-04-18, 10:47
  2. Datenübertragung AS400 --> Excel
    By Zuther in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 11-08-15, 10:09
  3. Daten via CSV von einer auf eine andere iSeries exportieren
    By ensöianer in forum IBM i Hauptforum
    Antworten: 7
    Letzter Beitrag: 04-12-14, 12:18
  4. Drucken mit polnischen Zeichensatz
    By Andreas Herzfeldt in forum NEWSboard Drucker
    Antworten: 3
    Letzter Beitrag: 27-06-01, 17:22
  5. Zeichensatz anzeigen
    By Burgy Zapp in forum NEWSboard Server Software
    Antworten: 0
    Letzter Beitrag: 03-04-01, 20:07

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •