Hallo,

vielen Dank erst mal für die rege Diskussion. Da aber hier diverse Dinge falsch verstanden werden, möchte ich die Situation erst noch ein wenig genauer erläutern.

Es geht hier nicht um die Ausführungszeit der Prozedur, sondern rein um den odbc_connect von PHP (@Fuerchau). Zu diesem Zeitpunkt wird noch keine Prozedur aufgerufen. Die Antwortzeit dabei hält sich zwar noch in Grenzen (ca. 0,5 - 1 sec.), jedoch wollen wir eben prüfen, ob es doch eine Möglichkeit gibt dies zu optimieren. Wir hatten inzwischen auch schon Connection Pooling und odbc_pconnect versucht, was deutlich was gebracht hat. Aber nach einer gewissen Zeit war die Webseite nicht mehr aufrufbar, so dass der Apache jedesmal neu gestartet werden musste und wir das wieder zurückgeändert haben.

Dann ist mir eben die Sache mit der MySQL Storage Engine eingefallen. Und da PHP ja am besten mit MySQL eingesetzt wird, dachte ich ich könnte mit dieser Storage Engine arbeiten, um Daten von der DB2 zu empfangen. Es würde sicher gehen, wenn wir nur die normalen CRUD-Operationen bräuchten. Das ist aber nicht so, sondern wir rufen bisher per SQL-CALL direkt externe Stored Procedures auf, die auf der iSeries erstellt wurden. Per ODBC funktioniert das auch. So wie ich jedoch die Doku zur MySQL Storage Engine verstanden habe, geht es damit offenbar nicht. Ich bin gerade dabei diese Storage Engine mal zu installieren und werde es mal testen. Bin mal gespannt was dabei herauskommt.

Dieter hat es eigentlich auf den Punkt gebracht. Es geht um den Vergleich der Treiber ODBC vs. MySQL Storage Engine. Und ob man über diese Engine eben auch SPs aufrufen kann.

Da diese SPs bzw. die dahinter liegenden RPG-Programme komplexe Daten ermitteln, müssen wir das so beibehalten. In einen SQL 4-Zeiler kann man das leider nicht verpacken.

Ich dachte halt, dass es evtl. schon mal jemand so verwendet hat.

Gruß,
KM