-
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 ?
-
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.
-
Zitat von Fuerchau
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?
-
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.
-
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.
Similar Threads
-
By Curious in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 06-04-18, 09:47
-
By Zuther in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 11-08-15, 09:09
-
By ensöianer in forum IBM i Hauptforum
Antworten: 7
Letzter Beitrag: 04-12-14, 11:18
-
By Andreas Herzfeldt in forum NEWSboard Drucker
Antworten: 3
Letzter Beitrag: 27-06-01, 16:22
-
By Burgy Zapp in forum NEWSboard Server Software
Antworten: 0
Letzter Beitrag: 03-04-01, 19:07
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks