SQL Fehlermeldung

[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