Einträge in QHST

[Fuerchau]

Ist die Locale nicht Sache des Scripts ?
Wird im Connect eine Locale angegeben ?

Ansonsten würde ich mal nach einem UNICODE-fähigen Treiber für Linux suchen, die müsse es ja auch geben.

Und was den Cast angeht, so kann man das schon dynamisieren wenn an Hand der Daten die CCSID erkennbar ist.

[KM]

Ist die Locale nicht Sache des Scripts ?
Wird im Connect eine Locale angegeben ?

Beim connect() selbst kann man keine Locale angeben. Jedoch kommen die Verbindungen, die mit pconnect() erstellt wurden, durcheinander, wenn man im PHP-Script ständig die Locale umschaltet. Deshalb gibt es pro Request eine eindeutige Verbindung, die danach wieder beendet wird. Wir haben damals in alle möglichen Richtungen getestet. Und es blieb nichts anderes übrig.

Ansonsten würde ich mal nach einem UNICODE-fähigen Treiber für Linux suchen, die müsse es ja auch geben.

Von IBM gibt's keinen. Gab's damals zumindest noch nicht.

Und was den Cast angeht, so kann man das schon dynamisieren wenn an Hand der Daten die CCSID erkennbar ist.

Anhand der Daten ist das ja nicht erkennbar. Es muß immer ein separater Parameter mit übergeben werden, der die Sprache kennzeichnet.

[BenderD]

Hallo,

was nicht ist, könnte aber wohl doch werden, sprich ein zusätzliches Attribut, das den Ländercode beinhaltet, dann wäre das mit einer entsprechenden View und Cast leistbar. Ob das natürlich Aufwands technisch rentiert, wenn das einzige Problem die vermüllte QHST ist...

mfg

Dieter Bender

Beim connect() selbst kann man keine Locale angeben. Jedoch kommen die Verbindungen, die mit pconnect() erstellt wurden, durcheinander, wenn man im PHP-Script ständig die Locale umschaltet. Deshalb gibt es pro Request eine eindeutige Verbindung, die danach wieder beendet wird. Wir haben damals in alle möglichen Richtungen getestet. Und es blieb nichts anderes übrig.


Von IBM gibt's keinen. Gab's damals zumindest noch nicht.


Anhand der Daten ist das ja nicht erkennbar. Es muß immer ein separater Parameter mit übergeben werden, der die Sprache kennzeichnet.

[Fuerchau]

Naja, ein Performance-Problem ist das allemal (Connect Open/Close).
Wenn zusätzlich noch die Wiederverwendung der QZDA-Job's ausgeschlossen ist, dann kann man ja die Antwortzeiten wohl vergessen.

Ausserdem können durch PConnect auch ODP's wiederverwendet werden. Ich denke auch hier sollte man mal überlegen.

Ggf. kann man doch Java aus PHP aufrufen um das Unicode-Problem zu lösen ?

[KM]

Also derzeit verwenden wir den "IBM DB2 ODBC DRIVER", der speziell für die DB2 optimiert ist. Dabei gibt es die Methode db2_connect(), um eine Verbindung zur Datenbank herzustellen. Das klappt von der Performance einigermaßen gut. Natürlich ist das bei weitem nicht so schnell wie ein Zugriff auf eine MySQL-Datenbank, die direkt auf dem Webserver liegt. Uns ist nämlich aufgefallen, dass der normale ODBC-Treiber und der connect() Probleme gemacht haben. Deshalb die Umstellung auf db2_connect().

Wir haben leider keine andere Möglichkeit gefunden eine DB2-Datenbank anzuzapfen. Die Variante "PHP mit Java" hört sich interessant an. Ich kann mir aber nicht vorstellen, dass das wirklich performanter sein soll. Außerdem wüsste ich jetzt nicht wie man sowas implementiert. Hat jemand damit schon mal Erfahrungen gesammelt und könnte mir ein Beipiel für einen Datenbank-Zugriff schicken ?

Kennt jemand noch andere Möglichkeiten für einen Datenbank-Zugriff aus PHP auf eine iSeries-Datenbank ?

Gruß,
KM