Datentransfer zum MS SQL-Server (CCSID?)

[flieger_siggi]

Hallo,
wir müssen Daten aus der i5 auf einen SQL-Server übertragen. Idealerweise sollte sie über eine OLEDB Verbindung vom SQL-Server abgeholt werden.
1. Problem: ich bekomme den Treiber nicht kopnfiguriert. Der Kontakt zur i5 funktioniert zwar, aber der Job auf der i5 läuft immer auf einen Fehler wg. unbekannter Zeichen, die vom SQL Server gesendet werden.

Also hab ich nicht OLEDB sindern ODBC genutzt. Fein, das geht, Daten sind da. Aber:
2. Problem: das Euro Zeichen in Textfeldern wird nicht korrekt übernommen. Alles andere schon.

Deshalb hier die Frage: kennt sich da jemand mit aus? Wer macht sowas schon regelmäßig und kann helfen?

Grüße

Siggi

[Fuerchau]

Das Euro-Zeichen ist tatsächlich ein Problem und kann nicht so einfach übernommen werden.
Bei der ODBC- (auch OLEDB-) Verbindung wird die Systemsprache als CCSID automatisch gesetzt. Bei Deutsch ist das nun mal 273.
Desweiteren liegt es an der CCSID der Datei.

Wenn nun ein Terminal mit 1141 das Euro-Zeichen eingibt, die Datei aber auf 273 steht, kann leider kein Eurozeichen zurückkommen.
Da nun SQL auch von Datei in Job-CCSID wandelt muss der Umweg über Unicode genommen werden.
Hier hilft nun mal wieder nur der berühmte 3-fach-cast:

cast(cast(cast(feld as char(nn) ccsid 65535) as char(nn) ccsid 1141) as graphic(nn) ccsid 13488)

Da die Daten ja in 1141 eingegeben sind aber in der Datei in 273 gespeichert wurden folgt der cast folgenden Regeln:

1. cast in *HEX = keine Umwandlung
2. cast in 1141 = keine Umwandlung
3. cast in 13488 = Umwandlung von 1141 in Unicode

Ggf. scheitert das noch am SQL-Server.
Da ja intern inzwischen immer mit OLEDB gearbeitet wird und der ODBC-OLEDB "MSDASQL" nicht Unicodefähig ist, kann es hier trotzdem zum Verlust des Eurozeichens kommen.

Korrekt wäre da trotzdem die Verwendung des IBMDASQL.

[flieger_siggi]

danke!

ich habe inzwischen mal die Daten über ein RPG Programm als ifs datei im csv Format ausgegeben. Ich habe die CCSID 1252 bei der Erstellung benutzt.
Dort stehen alle Zeichen jetzt korrekt drin. Ist aber eben csv...mühsam zu importieren...

Grüße
Siggi

[Fuerchau]

Enfacher gehts doch mit CREATE VIEW, die das alles enthält und dann aus der View importieren.

[flieger_siggi]

verstehe ich das richtig: du meinst, eine View so definieren, dass sie die Datenkonvertierung durchführt und dann diese in den SQL-Server importieren?

Grüße
Siggi

[Fuerchau]

Ja, warum denn nicht?
Dies gilt sowieso für diese Art der Zugriffe .

- kein Update/Insert/Delete möglich (= mehr Sicherheit)
- Konvertierungen, Anpassungen, Joins u.v.m.

Das Problem beim Zugriff über Linked-Server ist die Abfragetechnik ins besonders bei Joins. Das erledigt man besser über Views.

[BenderD]

... ich habe gerade mal mit ArdGate geklimpert, Job auf 1141 stellen, insert into... passt! (Seltsamerweise habe ich dann beim select von der AS/400 auf den SQL Server Probleme das in der Mocha Emu anzuzeigen...)

D*B

[Fuerchau]

Problem siehe oben:
QZDASOINIT geht per Default auf QCCSID bzw. Sprache des Users der sich anmeldet (USRPRF-Einstellungen).
Wenn QCCSID/USRPRF = *HEX, dann nimm aus Sprache die CCSID.
Bei DEU gibt das leider immer 273 und nicht 1141.

Wenn die Datei also auf 1141 steht, wird im SQL-Job auf 273 gewandelt und da geht das Euro-Zeichen verloren bevor es für den SQL-Server in ANSI übersetzt wird.

[BenderD]

Problem siehe oben:
QZDASOINIT geht per Default auf QCCSID bzw. Sprache des Users der sich anmeldet (USRPRF-Einstellungen).
Wenn QCCSID/USRPRF = *HEX, dann nimm aus Sprache die CCSID.
Bei DEU gibt das leider immer 273 und nicht 1141.

Wenn die Datei also auf 1141 steht, wird im SQL-Job auf 273 gewandelt und da geht das Euro-Zeichen verloren bevor es für den SQL-Server in ANSI übersetzt wird.

... falls Du das auf ArdGate beziehst, da gibt es keinen QZDASOINIT, die Daten gehen als binärdaten von RPG an Java und werden dort per JDBC nach und von SQL Server geschrieben/gelesen. Mit CCSID 273 kommt was anderes an, wie mit CCSID 1141. Bei 273 sieht AS/400 seitig alles toll aus (wohl MIMO Prinzip), bei 1141 ist die SQL Server Seite ok, aber beim lesen kommt was falsch umgesetztes bei DB2/400 an...

[Fuerchau]

Was die IBM-Schnittstelle angeht, so wird ja je Feld die CCSID der Daten mitgegeben, so dass die Umwandlung von dir vorgenommen werden müsste.
Welche Methoden da die Java-Toolbox der AS/400 bietet kenne ich nicht.
Java arbeitet ja bei Strings generell in Unicode, so dass bei der Umwandlung von Strings in SBCS-Daten und retour die richtige Codepage ausgewählt sein muss.

[BenderD]

... nicht ganz:
wenn der Job eine CCSID hat, wird auf SQL Ebene alles, was eine CCSID hat in die JobCCSID gewandelt (dabei geht bei 273 das Euro Zeichen flöten). Bei der Umsetzung innerhalb von ArdGate werden die Daten dann von der JobCCSID nach Java gewandelt (wird wohl UTF8 sein), der JDBC Treiber kümmert sich dann drum das in die Datenbank (hier SQL Server) zu schaffen.
Beim schreiben von DB2/400 in SQL Server funzt das mit 1141, mit 273 ist der Euro futsch (landet in einem Ersatzzeichen KennIchNicht).
Auf dem Rückweg ist im Java noch alles paletti und dann klemmt es irgendwo bei der Rückkonvertierun oder/und Anzeige (Umlaute OK Euro futsch.

D*B