Sonderzeichen bei ODBC

[Tommy]

Hi,

ich habe das CAE installiert und rufe per ODBC-Treiber in Excel die SQL-Daten ab. Ich muss immer feststellen, dass die Sonderzeichen (äüöß usw.) nicht richtig ankommen. Was muss ich ändern ? Bestimmt Einstellung in CAE! Aber wo ? :-\

Danke,

Tommy

[Fuerchau]

Der Fehler liegt warscheinlich darin, dass die AS/400-Dateien keine CCSID haben (bzw. 65535), so dass nicht korrekt umgesetzt werden kann. Überprüfen Sie ggf. den Systemwert QCCSID und stellen diesen auf 273.

In der ODBC-Konfiguration können Sie angeben, dass CCSID 65535 auf jeden Fall umgesetzt werden soll, dann nimmt CAE an, dass die Daten entsprechend Ihrer PC-Konfiguration die CCSID 273 haben. Dies löst aber ggf. nicht dieses Problem.

Wenn Sie allerdings über Excel das CAE-AddIn Datenübertragung von AS/400 nehmen, geben Sie bei der Übertragung den ANSI-Zeichensatz an. Die Default-Einstellung ist ASCII. Windows verwendet aber den ANSI !

[Tommy]

Hallo Fuerchau!

Danke für deine Hilfe.

Kann ich den SYSVAL ohne Bedenken ändern, oder führt das evtl. zu Probs ?

Grüße

Tommy

[Tommy]

Ich habe es geschafft !!

Ich habe in CAE in den allgemeinen Einstellungen (Start->Programme->IBM...->Client-Access Eigenschaften) den Wert von ANSI=Standard, OEM=Standart, CCSID=65535 geändert.
Jetzt geht's..

Danke Fuerchau.

Grüße an alle...

Tommy

[Fuerchau]

Der Systemwert kann ohne bedenken korrekt auf Ihre Sprache gesetzt werden.
Er betrifft im wesentlich alle NEU erstellten PF-Dateien in denen keine CCSID explizit angegeben wird. Diese Dateien werden mit der CCSID aus QCCSID erstellt.

Auf einem deutschen System empfiehlt sich daher GRUNDSÄTZLICH die Einstellung auf 273 !

[Paul]

Der Systemwert kann ohne bedenken korrekt auf Ihre Sprache gesetzt werden.
Er betrifft im wesentlich alle NEU erstellten PF-Dateien in denen keine CCSID explizit angegeben wird. Diese Dateien werden mit der CCSID aus QCCSID erstellt.

Auf einem deutschen System empfiehlt sich daher GRUNDSÄTZLICH die Einstellung auf 273 !

Auf der AS/400 haben wir die Datenbank mit Codepage 273 erstellt und Release V4M5R0
Wir benutzen Client Access 5.1 auf unseren PC's mit ODBC Version 8.00.00.00
Folgendes Problem tritt auf.
Durch Verwendung der Sonderzeichen für z.B. Ungarn haben wir Client Access wie folgt
eingestellt.
Tastatur = Ungarisch
Codepage = 870
Schriftart = Courrier New
Somit lassen soch alle Sonderzeichen in unserer Datenbank auf der AS/400 Darstellen.
Bei Verwendung des ODBC's mit MS-Access werden diese Sonderzeichen jedoch nicht
Sauber dargestellt.
Habe jetzt herausgefunden das evtl DB2 Client Application Enabler for WIndows hier
helfen könnte oder gibt es eine andere Lösung ?

[Fuerchau]

Auch DB2-Produkte können daran nichts ändern.
Das Problem ist, dass zwar ungarische Zeichen durch das Terminal erfaßt werden, aber in der Datenbank (273) als deutsch angenommen werden.
ODBC kann daher nur deutschen Zeichen reinterpretieren.

Auf dem Terminal werden die Zeichen deshalb "korrekt" angezeigt, weil die deutschen Zeichen als ungarische angenommen werden !

Um die Daten per ODBC auch als ungarisch zu erhalten, müssen die Daten in einer DB mit CCSID 870 stehen.
Aber Achtung:
Eine Codewandlung von 273 nach 870 ist nicht möglich und wird von der AS/400 abgelehnt.

Korrekt wäre:
Terminal auf 870
Job auf 870
DB auf 870

Dann klappts auch mit ODBC !

[KM]

Aber Achtung:
Eine Codewandlung von 273 nach 870 ist nicht möglich und wird von der AS/400 abgelehnt.

Das Problem hatten wir auch. Unsere Dateien waren auch zum Teil mit 273 erstellt. Und als dann ein Job mit CCSID 870 darauf zugreifen wollte sind die Programme auf die Nase gefallen. Deshalb würde ich folgender Aussage nicht unbedingt zustimmen:

Der Systemwert kann ohne bedenken korrekt auf Ihre Sprache gesetzt werden.
Auf einem deutschen System empfiehlt sich daher GRUNDSÄTZLICH die Einstellung auf 273 !

Gruß,
KM

[Fuerchau]

@KM

Doch ich bleibe dabei !
Wenn ich mit Mehrsprachigkeit umgehe sollte die DB eine korrekte CCSID haben. Entweder ich fange mit DBCS/Unicode an oder ich trenne per CCSID die Datenbank.

CCSID 65535 halte ich für grundsätzlich falsch, da man sonst nicht klar erkennen kann, woher die Daten denn sind.
Mischmasch mit Latin1 / Latin2 sollte man vermeiden (geht nämlich nicht) da auch andere Schnittstellen (ODBC, IFS) damit nicht zurechtkommen werden !

[henni]

Hallo
ich arbeite mit Paul an dem Problem.

Leider befinden sich sowohl deutsche Umlaute als auch z.B. Ungarische Sonderzeichen ( wohl falsch umgesezt aber dennoch ) in der Datenbank. Daher koennen wir den Laendercode nicht grundsaetzlich umstellen.
Soweit klappt ja auch alles. Wir bekommen die Eingabe und Ausgabe im Terminal hin und gedruckt wirds auch wie es soll. Nur Client Access ODBC muesste eine DLL benutzen um mit 870 wieder den gewuenschten Output zu bekommen. Zumindest bietet das ODBC setup eine moeglichkeit sowas einzubinden.


Da ist wohl was gleichyeitig geschrieben worden. /
Unicode ist sicherlich eine sinnvolle Loesung ,dazu muesste aber die Komplette Datenbank umgestellt werden. Was hier einen zu grossen aufwand darstellnen wuerde

[Fuerchau]

Die Umsetzungs-Dll muss aber entsprechend geschrieben werden.
Wie willst du aber mit den gemischten Daten umgehen ?
Vielleicht sind ja alle Zeichen in der DB vorhanden, also Umlaute und ungarisch !
Woran soll man nun die Korrektheit der Daten erkennen ?

Es gibt da einen kleinen Trick:
1. Version
Erstellen einer identischen Tabelle mit CCSID 65535 !
Erstellen einer identischen Tabelle mit CCSID 870 !

Per Insert/Select die Daten aus der Tabelle mit 273 in die mit 65535 und von da aus weiter nach 870.
Durch den Zwischenschritt mit 65535 erfolgt keine Codewandlung !

2.Version
select cast(cast(myfield as char(len) for bit data) as char(len) ccsid 870) as myfield

Ob das allerdings korrekt funktioniert kann ich nicht sagen, das Statemente ist so korrekt.