Datentransfer zum MS SQL-Server (CCSID?)

[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