-
Das Hauptproblem bei CCSID 65535 ist, dass die Daten dann als Binärdaten interpretiert werden.
SQL-Serverjobs (ODBC, DRDA, ArdGate) werden aber NIE ohne CCSID ausgeführt.
Steht also das System (QCCSID) auf 65535 werden diese Jobs automatisch mit 037 (amerikanisches Englisch) ausgeführt.
Durch die Weitergabe von Binärdaten an den Serverjob wird daher nun als Datenbasis 037 an Stelle von 273 angenommen was zu falscher Codewandlung führt.
Warum das nun aus STRSQL heraus funktioniert und nicht aus embedded SQL kann ich im Detail nicht feststellen, aber man sollte mal die CCSID des ArdGate-Jobs prüfen.
Generell gilt:
Sobald auf irgendeiner Ebene die CCSID 65535 (*Hex, Binär) eingestellt ist, wird es bei der Codewandlung Probleme geben.
-
... der ArdGate Job kann überall laufen und braucht keine CCSID, der wird asynchron mit Binärdaten, die von DB2 CCSID Informationen bekommen, per DataQ bedient; diese CCSID Informationen hängen unter anderem vom Job ab, der SQL über ArdGate benutzt. ArdGate hat auch keine Kenntnis, ob eine Anforderung aus STRSQL, aus QMQRY, aus RUNSQLSTM oder aus embedded SQL kommt, das äußert sich allenfalls mittelbar in der Verwendung Parmeter Markern. Ich tippe mal eher auf die Herkunft der Daten.
D*B
-
Dazu kenne ich jetzt deine Implementation nicht.
Ich nehme aber mal an, dass dir die Zeichendaten immer in EBCDIC von der Schnittstelle übergeben werden (solange es nicht UCS2 ist).
Beim Schreiben in die Zieldatenbank (bzw. auch beim Lesen) muss also irgendwo die Codewandlung durchgeführt und eine CCSID-Entscheidung getroffen werden.
Die Frage ist nun, wo SQL bei der Übergabe an die Schnittstelle selber noch mal eine Codewandlung durchführt, da ja die Quelljobs und somit auch die Daten durchaus unterschiedliche CCSID's haben können.
Was aus der IBM-Doku leider nicht hervorgeht ist bei ILE, wie die CCSID-Information des Modules (die es bei OPM ja nicht gibt), auf SQL zur Laufzeit mit Programmkonstanten wirkt.
Auch gibt es natürlich einen Unterschied, ob der SQL selber Konstanten hat oder die Konstanten in Hostvariablen übertragen und dann verwendet werden.
Ich habe da noch keine Zeit gehabt, dies mal mit diversen CCSID's (Quelle, Job) auszuprobieren.
-
Nachtrag:
Ich habe es soweit gefunden.
Man sollte also mal das Log einschalten und die CCSID suchen, die übergeben wird.
Mit dieser CCSID wird dann die Funktion AS400Text ausgeführt.
-
... wenn es denn daran liegt! Wenn z.B. aus einer Datei schon Schotter kommt, weil man deren CCSID schon mal geändert hat (das ändert ja die Daten nicht!), dann hilft die beste CCSID und Umsetzung nix mehr.
D*B
Similar Threads
-
By MKl. in forum IBM i Hauptforum
Antworten: 6
Letzter Beitrag: 14-12-06, 16:43
-
By y-tom in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 29-05-06, 15:31
-
By muadeep in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 28-02-06, 16:43
-
By mott in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 26-10-04, 09:56
-
By stadtmm in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 26-05-04, 17:02
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