Re: Trying to decide whether to support DB2 or Oracle

> You should have the commands "GET ROUTINE" and "PUT ROUTINE". That way,
 you
> compile the STPs once on your build machine (A), run GET ROUTINE, copy the
> file created there to the machines (B) you want to install the STPs on,
 run
> PUT ROUTINE ON B and you're all set. No need for a C compiler on B.

The problem with that is the need to have every machine-type we need to support. We aren't a huge development shop with access to every machine and processor that DB2 runs on. This isn't feasable, practical or even reasonable. The whole idea of an RDBMS language like SQL is to be platform agnostic, at least within a single RDBMS. As I said in an earlier post on this topic - for Oracle, the whole process is simple - I create DDL, Stored Procedures, Stored Functions, Etc. in a single text file. I pass that text file to a server (any Oracle server, it could be running UNIX, it could be running Windows, it could be running anywhere for all I care) and it creates the tables, indexes, stored procedures, stored functions, packages, everything. No C compilation, no anything. It just works. It is ubiquitious.

For DB2, not really. This is a severe design flaw in my opinion. You might as well require a C++ compiler for everything. How big would the customer pushback be if your messaging was "to create a table, please install a C++ compiler". Ohhhh - you want an Index? First, install a C++ compiler, and we'll take care of that for you.

Ludicrous? Maybe. But that is the deployment solution DB2 is providing ISV's who need stored procedures for application performance and isolation. If it is getting fixed in a future fixpack, great. I can hardly wait. But posting that the problem is "already addressed" is misleading. It is *not* addressed. It is kludged perhaps if you have heterogenous machine-to-machine deployments. But in this day, what ISV has that? There is no work-around.

Marc Received on Tue May 08 2001 - 00:44:07 CEST