View Full Version : SQLRPGLE und Umlaute
Hallo Forum
beim insert in eine Tabelle in eine Microsoft SQL 2005 Datenbank via SQLRPGLE werden die Umlaute in Hyroglyphen umgesetzt.
Beim insert im Dialog via strsql NICHT.
Das Feld ist in der Datenbank varchar definiert und wird aus einem charfeld im SQLRPGLE befüllt.
Vielen Dank für Tipps.
Franco
... da es sich nur um ArdGate handeln kann (sonst kann das keiner) bräuchte ich von einem minimalisierten Beispiel:
(insert into testdatei values(1, 'AäöüßAÖÜZ')
einmal interaktiv ausgeführt und dazu das ausführliche Java log (log4j.properties auf DEBUG stellen)
dann dasselbe ausgeführt als Programm (bitte separates log)
zusätzlich Programmquelle und Kopie der interaktiven Sitzung (bitte kein Image, sondern Textkopie mit cut and paste) unde von einer interaktiven Sitzung die Ausgabe von:
select * from testdatei (bitte nur die 2 Sätze), schün wäre auch die Hexausgabe
select hex(mytextfeld) from testdatei
dann sollte sich der Fehler finden lassen
Ich gehe mal davon aus, dass fdh eine Art Monogramm ist, meine eMail Adresse also bekannt ist
mfg
D*B
in der Tat ein Monogramm ein Kalogram.
Franco Daniel Herrmann
oder
nach 20 Kg Gewichtsabnahme auch Friss die Hälfte
in der Tat handelt es sich um Ardgate.
Dir Informationen sind unterwegs.
FDH
Wie steht denn die CCSID der RPG-Quelle und die CCSID des Jobs zur Compilezeit ?
Wie steht der Systemwert QCCSID ?
Bei SQL gibt es einige Ebenen der automatischen Code-Wandlung, ein Programmobjekt und die enthaltenen Konstanten werden zur Compilezeit von der Quell-CCSID in die Job-CCSID gewandelt, zur Laufzeit MUSS daher der Job genau die richtige CCSID haben, damit Programmkonstanten dazu passen.
Hallo Fuerchau,
Danke für die Information.
QCCSID steht auf 65535. Ebenso die des Objektes und der Datei.
Bei unseren vielen Versuchen wurden jeweils die jobccsid mit chgjob geändert und soweit möglich vorher ebenso die Datei- und Objektangaben.
Am Montag wird weiter getestet.
Kollege Bender hat uns eine geänderte JAR für Ardgate geschickt ...
Franco
... also ich habe bei mir ein SQL Server 2008 Express laufen.
Dort bemutzt meine Tabelle als Sortierfolge
latin1_general_ci_as, wie MS das vorschlägt.
Ich verwende AS/400 seitig CCSID 273 für den Job, wie man das für deutsch üblicherweise tut. Ich bekomme mit STRSQL über ArdGate alle Umlaute korrekt angezeigt, kann Wörter mit Umlauten einfügen, die auch mit Microsoft SQL Server Management Studio korrekt angezeigt werden. Sätze, die ich im Management Studion einfüge , werden auf der AS/400 korrekt angezeigt.
Bei Programmen habe ich bezüglich Sprachen keine besonderen Einstellungen, meine Quelldateien haben CCSID 273 und der Job läuft bei der Wandlung unter CCSID 273, ebenso hat der Job zur Laufzeit CCSID 273, Die Eingaben mit Umlauten kommen aus Programm Literalen, oder aus Dialogeingaben, werden per ArdGate geschrieben, Es werden prepared Statements mit Parameter Markern verwendet, die ihre Inhalte aus Programmvariablen (keine Dateifelder AS400) bekommen. Die Daten kommen dort richtig an (Kontrolle mit Management Studio). Sätze von MS SQL Server Dateien werden auch korrekt in das Programm eingelesen.
Ich habe für die letzten Tests den aktuellen Stand von ArdGate verwendet, wie er auf SourceForge zu finden ist, konnte obige Probleme bei mir aber vorher schon nicht verifizieren.
Die Angabe Hyroglyphen ist leider auch ein wenig unspezifisch, eine genaue Angabe welcher Umlaut wie ankommt wäre da zielführender.
Hier noch ein paar grundsätzliche Hinweise für Fehlermeldungen Open Source Software (gilt analog auch vielfach für gekaufte Software, selbst bei Wartungsverträgen).
- Fehler müssen vollständig und detailliert beschrieben werden, geht nicht, oder Hyroglyphen ist da meist nicht ausreichend.
- Fehler müssen reproduzierbar gemacht werden, wenn möglich Beispielprogramme (die natürlich in sich abgeschlossen sein müssen) in minimalisierter Form.
- Angabe der Software Version (bei ArdGate zum Beispiel Datum der ArdGate.jar)
- Für Open Source ist noch zu beachten: Man nutzt die Software ohne Gebühr, diese übernimmt keine Garantien. Fehleranalyse und Behebung erfolgt ohne Berechnung. Die Autoren von Open Source sind keine Gutmenschen (ich zumindest nicht), haben aber Interesse an der Qualität des Produktes, da sie es selber einsetzen. Die Art der Aufbereitung der Fehlermeldung hat entscheidenden Einfluss auf die Priorisierung; minimalisierte Beispiele, vollständig beschrieben, die den Fehler reproduzierbar machen, haben immer die Chance auf Top Priorität.
D*B
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.