Jon,
Well, I know Rochester tells you DB2/400 is UDB but it isn't, not as far as the
rest of IBM is concerned. DB2/400 is DB2/400 and is not considered, really, as
the real DB2 UDB by the rest of IBM's platforms and software manufactures that
build software for IBM's platforms.
As to where PHP is running and what it can access, you provide some valuable
information that might sway me away from PHP unless they can convince me it's
not using ODBC to send SQL to the engine.
As to RPG... well, if you've every read any of my thoughts on that orphan and
non-standard language, you'll know that I will RUN from ever using RPG,
especially when there are industry standard, world-recognized and somewhat
modern languages even on the i5, such as C.
As to stored procedures... go thing to use and, I often create SQL stored
procedures if I don't NEED the logic capabilities of a language. The point
being why make a stored procedure complex with a language if SQL as a stored
procedure will do.
Thanks,
Dave
"Jon Paris" <Jon.Paris@xxxxxxxxxxxxxx> 6/6/2007 07:17 >>>
It appears like the two URLs you send don't speak to DB2/400 SQL access
using static SQL. The first is about regular UDB DB2 which DB2/400 isn't.
The latter, I assume, is native i5 I/O as used by RPG or the like, not SQL.
DB2/400 is UDB DB2 - has been for a while.
You are running PHP in PASE so it would be very surprising if it could
access pre-prepared packages - which is what happens with embedded SQL in
RPG programs. I assume that is what you mean by "static SQL". If you want
static SQL then you do it within RPG programs and either call them or use
them as stored procedures. I suspect that the DB2 uses DRDA. But it is
"special" - not ODBC. Zend built this stuff directly on top of IBM's APIs.
Jon Paris
Partner400
www.Partner400.com
As an Amazon Associate we earn from qualifying purchases.