Unicode: UCS-2 (13488) oder UTF-8 (1208)

[DSB]

Vielen Dank für dei Antwort.

Für abweichende Benutzer-Einstellungen kann man im USRPRF noch eine LOCALE angeben

Wie eingangs erwähnt ändert eine andere Einstellung der CCSID im Userprofil leider nichts. Die Vorschläge bzgl. LOCALE fruchten auf unserem System leider nicht, da es weder eine QSYSLOCALE noch eine QLANGID zu geben scheint. (Sorry, ich kann das technisch nicht vernünftig ausdrücken, da ich mich mit PHP beschäftige und mit dem AS400-Umfeld an sich wenig zu tun habe).

Wird der SQL insgesamt zusammengebaut, so muss bei der Verbindung bereits eingestellt werden, dass der gesamte SQL-String als UCS2 übergeben wird.

Genau das ist ja meine Frage. Wie "sage" ich der Verbindung, dass ich ucs2 empfangen möchte und ebenso senden werde?
Ich arbeite mit IBM DB2, Cloudscape and Apache Derby Functions und finde keinen Weg das gezielt zu steuern.

[Fuerchau]

DB2-Cloudescape hat ja mit AS/400 nix am Hut sondern ist eine ja eine eigene DB.
CCSID's spielen da überhaupt keine Rolle, da ja sowieso alles in Java ist (Unicode ist da Standard).

Die QSYSLOCALE kann separate installiert werden und ist eine Bibliothek.
Man kann dann eine Locale erstelle (z.B. DE_DE.locale) und diese dem USRPRF zuordnen. Desweiteren gibt man im USRPRF dann an, dass die CCSID aus der Locale beim Job angewendet werden soll.

QCCSID und QLANGID sind Systemwerte (WRKSYSVAL).

Wie nun die Verbindungseinstellungen über PHP gemacht kann ich nicht sagen.

Über ODBC kann man in der Konfiguration angeben dass der SQL-String selber als Unicode gesendet werden soll.
Dies betrifft SQL's, die eben zusammengebaut werden, wie:

"select ... from myfile where key='abcd'"

Bei Verwendung von Markern entscheidet der Parametertyp:
"select ... from myfile where key=?"
Der SQL selber muss hierfür nicht in Unicode sein.

Beim Lesen von Resultsets/Recordsets sind die Unicode-Spalten auch automatisch in Unicode, da dies durch die Tabelle bestimmt wird. Eine Umsetzung ist da nicht erforderlich.

[DSB]

DB2-Cloudescape hat ja mit AS/400 nix am Hut sondern ist eine ja eine eigene DB.

Ich kann damit auf die bereits im System vorhandenen Datenbanken zugreifen (und genau dafür ist diese PHP-Extension auch gedacht). Wäre es ein eigenes DB-System, so wären keine Daten vorhanden und man müsste erst Datenbanken/Tabellen anlegen.

CCSID's spielen da überhaupt keine Rolle, da ja sowieso alles in Java ist (Unicode ist da Standard).
...
Beim Lesen von Resultsets/Recordsets sind die Unicode-Spalten auch automatisch in Unicode, da dies durch die Tabelle bestimmt wird. Eine Umsetzung ist da nicht erforderlich.

Das kann ich nicht bestätigen und stimmt so nach meiner bisherigen Forschungsarbeit nicht! Wenn Deine Annahme stimmen würde, dann bekäme ich bei einem SELECT Zeichen in Unicode. Das ist aber nicht der Fall - ich bekomme die Zeichen in ISO 8859-1 geliefert (mein User ist auf CCSID 273 eingestellt).

Intern hat das System, und optional jede Datei, jede Datenbank und jede Tabelle eine eigene CCSID. Ist keine vorgegeben, so greift die CCSID der übergeordneten Instanz.
Je nach zugreifendem Prozess/User, der ebenso eine CCSID besitzt, wandelt die AS400 die Zeichen in den jeweiligen Zeichensatz wenn sie sich unterscheiden und zwar in beide Richtungen (lesen/schreiben).

Dies erscheint auch logisch. Wenn Zeichenketten in einem SQL-Query übergeben werden, dann muss bekannt sein, wie diese interpretiert werden müssen, damit die AS400 weiß von welchem Quellzeichensatz in welchen Zielzeichensatz konvertiert werden muss.

[Fuerchau]

Du benutzt dann nicht die Cloudescape selber sondern nur den DB2-Zugriff zur AS/400.
In diesem Fall hast du natürlich Recht.
Soweit ich bei Cloudescape nachlesen konnte, handelt es sich dabei auch um eine embedded oder auch Servervariante einer in Java geschriebenen Datenbank.

Zu diesem DB2-Connect selber kann ich nichts sagen.
Greife ich aber über ODBC bzw. OLEDB auf die AS/400 zu, werden UCS2-Felder einer Tabelle auch als UCS2 (WChar) im Resultset geliefert.
Beim Schreiben über Command-Objekte mit Parametermarkern und eigener Definition als WChar, werden die Daten auch korrekt als UCS2 in die DB geschrieben.
Eine Umwandlung der Zeichen erfolgt generell nicht.

Für alle anderen CCSID's des Typ's SBCS gilt natürlich die Umsetzung in den entsprechenden Zeichensatz, wobei auf der AS/400 die Job- und DB-CCSID gilt und lokal die Windows-Spracheinstellung (bei mir eben Codepage 1252).

[DSB]

Greife ich aber über ODBC bzw. OLEDB auf die AS/400 zu, werden UCS2-Felder einer Tabelle auch als UCS2 (WChar) im Resultset geliefert.
...
Für alle anderen CCSID's des Typ's SBCS gilt natürlich die Umsetzung in den entsprechenden Zeichensatz

Ah, das könnte der kleine aber feine Unterschied sein. Bisher habe ich noch keine UCS2-Felder definiert, da ja bereits bei den anderen Feldern Konvertierungsprobleme auftreten.
Ein reines UCS2 Feld werde ich gleich einmal testen und Bericht erstatten.
Vielen Dank.

[DSB]

Hier ist auch noch einmal eine Quelle, die Fuerchau's Aussagen noch einmal bestätigen. Vielleicht ist das für den ein oder anderen noch einmal nützlich:
Release Notes
Release Notes

Es spielen so viele Faktoren eine Rolle, dass ich mittlerweile verunsichert bin, Fehlerquelle für Fehlerquelle ausschließen will und das noch einmal in aller Ruhe durchtesten werde. Drückt mir die Daumen.