RE: IIS to as/400 odbc

Walden, for me I'm still undecided about stored procedures.  They have great
potential, although I think you'll agree that, like exit programs, a
majority of companies that implement ODBC do not implement it purely as
stored procedures.

That aside, stored procedures is an approach that is almost equivalent to a
message-based architecture, with the benefit of industry standards and only
a couple of weaknesses.

PRO
A. Industry standard interface

CONS
A. Return only homogenous data
B. Don't allow sets of data as INPUT to the stored procedure

It's a tradeoff at this point.  If what you're doing is querying homogenous
blocks of data, then stored procedures do indeed have a lot of potential.

On the other hand, with a solid message-based architecture, you get the
ability to retrieve heterogenous blocks of data, which is especially
important when you have high-volume header/detail types of queries.  With
SQL, you must repeat the header information on every row of the detail
unless you perform two separate queries.

Also, you can only add or update a single record at a time.  I'm sure you
can send a REALLY BIG record and break it up, but that's not what I'm
talking about.  I'm talking about sending arbitrary amounts of arbitrarily
formatted data, such as would be required for, say, production sheet
maintenance, where you send up the entire routing and bill of materials for
a product, or order entry, where you send up header, detail and notes
information all at one shot - or a whole raft of orders in a single
document.

So I guess my question is, if you're taknig the time to write stored
procedures, why not invest a little more time and have a true message-based
system?

Joe


> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Walden H. Leverich
> Sent: Wednesday, August 15, 2001 7:00 AM
> To: 'midrange-l@midrange.com'
> Subject: RE: IIS to as/400 odbc
>
>
> Joe,
>
> While I agree with your assessment of A, B and C I think you are making a
> flaw in what a command is. It looks as if you are assuming that a
> command is
> "select * from file..." or "update file set..." or "delete from file..."
>
> What if the commands allowed from the web server are limited to "call ..."
> These stored procedures can return result sets satisfying the need for
> select and can obviously update and delete rows. Whenever I add a
> new table
> I need a new set of stored procedures (in RPG, Cobol, C, whatever) that
> allows me access to them and I don't need to change the list of
> things in my
> exit point.
>
> The other advantage to this is that the user (web server) is isolated from
> data layout changes on the AS/400. If I want to split a table, or change
> something so when a record in inserted into one table an audit record is
> inserted into another all I have to do it change the stored
> procedure. There
> is ZERO impact on the web server.
>
> -Walden