SQL Fehlermeldung

[Fuerchau]

Ich kenne jetzt PHP nicht, aber vielleicht kannst du die Prozedur ja mit Parametermarkern (Prepared Statement) aufrufen. Dann stellt sich das Problem von Sonderzeichen nicht, da der Parameter-Wert ja dann nicht Bestandteil des SQL's ist.

Ansonsten ist immer zu beachten, dass einfachen Hochkomma in Textkonstanten verdoppelt werden müssen.
Ggf. (siehe Birgitta's Hinweis) ist bei Konstanten Parametern ein CAST erforderlich:
... cast('Text' as char(30)) ...

Zeichen kleiner Blank werden in SQL auch häufig missverstanden. In diesen Fällen ist ggf. in Hex (X'....') umzuwandeln, wobei das ja die Codewandlung noch selber gemacht werdn müssen.

[KM]

Dieser Fehler lag an einer Einstellung des Webservers. In der locale für die Sprache stand de_DE.UTF8. Jetzt haben wir de_DE eingestellt und damit kommt der Fehler nicht. Allerdings kommen die Umlaute offenbar mit der falschen Codierung im Programm an. Wenn ich z.B. abcäö von der Webseite aus übergebe, dann erhalte ich auf der iSeries abcÀö. Könnte das für die Umlaute evtl. Unicode sein? Nur wie kann ich jetzt dieses Problem wieder beseitigen........??? Man kommt wirklich vom Regen in die Traufe mit diesen verfl...... Zeichensätzen.

Gruß,
KM

[Fuerchau]

Das ist fehlerhafte Übersetzung des SQL's nach EBCDIC.
Der SQL selber unterliegt natürlich immer einer Codewandlung nach EBCDIC und die erfolgt per JOB-CCSID !!!
Ist die JOB-CCSID eben 65535, wird ggf. 037 (USA) oder der Systemwert angenommen.
Wie du siehst, ist das Thema CCSID nicht auf die Daten der Tabellen beschränkt.

Seit V5R1 kannst du auch UNICODE-SQL's abgeben. Dies ist eine Treibereinstellung allerdings des CA-Treibers.
Wi das beim Java-Treiber geht: k.A.

[KM]

Ich bin jetzt mit meinem Problem ein ganzes Stück weitergekommen. Allerdings fehlt mir immernoch der letzte Schritt bis zur optimalen Lösung. Ich habe jetzt folgendes eingerichtet bzw. ausprobiert:

1) Die locale des Linux-Servers (auf dem der Webserver und der iSeries ODBC-Treiber für Linux läuft) stelle ich wahlweise auf de_DE bzw. pl_PL (je nach Sprachraum).

2) Im iSeries ODBC-Treiber für Linux habe ich UNICODESQL eingestellt.

3) Bei der Stored Procedure, die über SQL-Call via ODBC aufgerufen wird, habe ich sämtliche Input-Parameter vom Typ CHARACTER mit CCSID 1208 definiert.

Wenn ich nun die Zeichencodierung der Web-Seite auf ISO-8859-1 bzw. ISO-8859-2 (je nach Sprachraum) umstelle und irgendwelche Sonderzeichen in eine Form eingebe, dann werden diese korrekt über die Stored Procedure im UTF-8 Format an die iSeries geschickt.
Wenn ich die Zeichenkodierung im Browser jedoch auf UTF-8 einstelle (so wie wir das geplant haben), dann kommen die Sonderzeichen falsch an. Es werden dann die entsprechenden ANSII-Zeichen geschickt, die zum betreffenden UTF-8 Hex-Code passen.

Hat jemand dafür eine Lösung? Wie kann ich nun erreichen, dass bei Zeichenkodierung UTF-8 auch wirklich die UTF-8 Zeichen geschickt werden?

Gruß,
KM

[Fuerchau]

Unicode ist UCS-2 und auf der AS/400 GRAPHIC(xx) CCSID(13488).
Versuche es mal damit oder alternativ mit UTF-16 (nahezu Unicode).
Auf der AS/400 ist auf jeden Fall CCSID 13488 für Unicode/UCS-2 zu nehmen.

[KM]

Arbeitet denn niemand mit dem iSeries Access ODBC Treiber für Linux ??? Ich kann mir irgendwie nicht ganz vorstellen, dass ich der einzige bin, der die Probleme mit UTF-8 und dem Linux ODBC-Treiber hat. Mit dem ISO-Zeichensatz funktioniert ja alles. Da wir aber für unseren Internet-Auftritt unterschiedliche Zeichensätze verwenden müssen, ist das so nicht praktikabel. Deshalb müssen wir unsere Seiten in UTF-8 codieren. Wenn ich dann aber die locale auf de_DE.utf8 ändere, meldet mir der SQL-Call immer SQL0104. Passiert das sonst niemandem ?

Gruß,
KM

[TARASIK]

Hallo KM,
bei IBM gibt es diese Info dazu:
http://www-1.ibm.com/support/docview...075696e&rs=110

[Fuerchau]

Tarasik, das ist ja ein Hinweis, den ich fast vermutet habe.
Wie es laufen könnte (unter Windows klappt das):

Alle SQL's zwingend mit Parameter-Markern. Beim 1. Zugriff, z.B. auf die Parameters-Auflistung, wird der SQL bereits prepared und die Parameter mit Anzahl und Typ ermittelt.
Default werden Text-Parameter aber als normale Zeichenketten definiert. Dies kann man ändern auf z.B. WideCharacter (UCS-2).
Das ClientProgramm muss allerdings von UTF-8 in WideCharacter (UTF-16/UCS-2) und zurück selber konvertieren. Was aber eigentlich kein Problem darstellt, da dies die Programmiersprachen schon fast selbständig tun.

Ob der SQL-String selber in Unicode übertragen wird ist unerheblich.
Auch die CCSID des Job's spielt keine Rolle, da SQL nur invariante Zeichen verwendet. Werden alle Parameter und auch die Ergebnisse eines Select's in WideCharacter verarbeitet gibt es keine Probleme mit der CCSID.

[KM]

Hallo zusammen,

es hat jetzt zwar lange gedauert, aber ich denke, dass ich nun sämtliche Probleme lösen konnte. Ein wichtiger Hinweis war, dass der iSeries Access ODBC Treiber für Linux kein Unicode-Treiber ist. Das hat mir die meisten Probleme bereitet, so dass ich nun ständig zwischen den einzelnen Codepages hin- und her konvertieren muß.

Wenn ich z.B. von einer Form einer Website (mit UTF-8 encoding) Daten an die iSeries schicken will, muß ich die locale des Webservers dynamisch je nach Sprache entsprechend einstellen (z.B. "pl_PL" für polnisch). Hier darf ich jedoch nicht ".utf8" anfügen, da der Treiber ja nicht unicodefähig ist un dich sonst den SQL0104-Fehler erhalte. Außerdem müssen die Daten zunächst in PHP von UTF-8 nach z.B. ISO-8859-2 konvertiert werden (z.B. mit der Funktion mb_convert_encoding), bevor sie an die iSeries geschickt werden, damit sie dort richtig ankommen. Im RPG-Programm muß ich dann wiederum von CCSID 1208 nach 1153 konvertieren. Wichtig dabei ist, dass die Parameter der Stored Procedure auch mit CCSID 1208 definiert wurden. Nur wenn das alles gemacht wird, kommen die Daten richtig in meiner iSeries-Datei an.
Zu beachten ist auch, dass nach jedem Aufruf die ODBC-Verbindung (QZDASOINIT-Jobs) wieder beendet wird, damit der nächste Benutzer, der vielleicht deutsch benutzt, nicht versehentlich die ODBC-Verbindung mit der locale "pl_PL" verwendet. Dann würden seine Daten nämlich falsch ankommen. Die Verwendung der einzelnen QZDASOINIT-Jobs kann man leider nicht ansteuern. Ich hab zumindest nichts darüber gefunden. Die ODBC-Verbindungen dürfen also nicht persistent sein, was leider zu längeren Wartezeiten führt.
Bei der Rückgabe von Daten aus einer iSeries-Datei im UTF-8 Format gibt es wieder andere Dinge zu beachten. Aber das will ich jetzt nicht mehr weiter erläutern. Das würde zu weit führen.

Alles in allem war das Ganze jetzt ein riesen Aufwand. Aber ich denke es hat sich gelohnt, da es jetzt schließlich doch funktioniert Daten zwischen einer Web-Seite und der iSeries-Datenbank in den unterschiedlichsten Zeichensätzen auszutauschen.

Danke nochmal an die Ideengeber.

Gruß,
KM