RE: IIS to as/400 odbc

Walden, I wrapper all of my communications in objects, so the details are
never exposed to "front end" programmers anyway.  However, I have full
control over my protocols so that I can add features, move databases, and so
on without their knowledge.

If the issue is a standard programming interface, that's pretty easy.  An
SQL result set is an iterator with a getField interface.  There's nothing to
supporting that same interface from a message-based system as well.
Besides, a GOOD programmer can use any interface, and a good O-O programmer
shouldn't care a lick about where their data is coming from.  If, on the
other hand, they're interested more in having marketable skills than in
building systems, then that's a different issue.

If the issue is being able to use SQL-like syntax on queries, well that's an
issue more for end-user queries than programmers.  I have yet to meet a
programmer who actually liked formatting the a SELECT statement, much less
an UPDATE statement.

Returning multiple results sets is not as powerful as a heterogenous message
list.  With multiple results sets, you have to still maintain cursors in
each set and perform what amounts to matching record logic to keep the
cursors in sync.  Not at all as easy as simply iterating through a list and
executing code based on message type.

As to XML for upload, you're pretty much conceding that ODBC won't work
here.  Instead, you're talking about a different access method entirely.
With a message-based approach, you have a consistent interface for both.  If
you use ODBC for one side and XML for another, that's inconsistent.

However, if you're highly vested in ODBC and your architecture is unlayered
and you don't wrapper your server requests and your programmers are
inflexible and your management is clueless, then sure, ODBC is the way to
go.

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 10:36 AM
> To: 'midrange-l@midrange.com'
> Subject: RE: IIS to as/400 odbc
>
>
> Joe,
>
> I'll agree with you _only_ in the case of the AS/400 community. Stored
> procedures are the standard for data access in the SQL Server, Oracle,
> Sybase, DB2 etc. world (at least in large environments, I'm not counting
> anyone that considers 1000 rows a large table.) You are correct that you
> need to perform separate queries to gather header and detail but in most
> cases you can return that in a single call as two record sets (I think. I
> know I can from SQL Server. I think I can from the AS/400) As far
> as sending
> multiple rows to the AS/400 in one shot, what about XML? Send the routing
> and bill of materials up as a single XML document and strip is
> out up there.
>
> The biggest advantage to using stored procedures and ODBC (or actually
> OLE/DB) in an ADO environment is that I don't have to teach my front end
> programmers anything about the AS/400 or proprietary interfaces. Every
> (good) ASP programmer knows how to use ADO to access a stored procedure. I
> don't care if that procedure is on SQLServer or the AS/400 -- or both!
>
> One of the biggest problems the AS/400 has is that it is considered
> proprietary (and in many cases it is.) The unfortunate reality is
> that if I
> can say to a client that they'll be using "industry standard, modern"
> interfaces to access the as/400 they might leave it in as the
> core of their
> environment. If, on the other hand, they think they'll be creating more
> "AS/400 specific, closed, proprietary, old fashioned,
> mainframe-like, tired,
> slow, boring, difficult to maintain, and expensive" code then they're more
> likely to move to some "new, open, cheap, better, faster, cool"
> system like
> SQL Server. While we may not agree with the quotes, I doubt anyone will
> argue that they represent the feeling of many AS/400 customers.
>
> -Walden