RE: IIS to as/400 odbc

["Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>]

Hmmm... This is turning into a religious argument, but they're always fun...

My comments are inline.

-Walden

PS. What's better Excel or Lotus 1-2-3? <G>

-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: Wednesday, August 15, 2001 11:58 AM
To: midrange-l@midrange.com
Subject: 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.

>>I don't have "full control" of my protocols, yet "I can add features, move
databases and so on without [programmer] knowledge." If I want a new feature
I add a new stored procedure. Yes, the programmer needs to call the new SP
to use the new feature, but the same is true in your case. My database
updates _are_ done through objects -- unless you're definition of "objects"
requires Java. A simple RPG program can be an object, if it's done right.
<<

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.

>>I agree that a GOOD programmer can pick up any interface, and often just
about any language. However I disagree about the use of the word "standard."
You're creating a new interface, not using a standard one. Granted the
components of the interface are standard (interators, getField, etc.) but
the interface itself is proprietary. And much as we may dislike it "resume
building" is a fact of life. It's much easier to attract and _retain_
programmers that can say "I've used ADO and OLE/DB to do this and that" than
it is when they have to say "I have a _ton_ of experience using Joe's
proprietary interface that has no bearing at your site."
<<

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.

>>Agreed. I wasn't proposing using SQL-like syntax, the CALL statement
excluded. Of course if there is a reason for me to do it (perhaps a complex
where clause) I have the option.
<<

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.

>>Ah, but what about the ability in ADO to have a recordset as a field.
Using the SHAPE provider I can actually return the header records in a
result set. Field one in the row is the customer id, field two the customer
name, field three the order number and field four is actually an entire
recordset representing the order lines in that set. Of course each of those
rows could have a field that was another record set.
<<


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.

>>Not entirely. The interface would still work, I'm simply sending XML as a
field value. I would prefer to see each of the rows sent to the insert
statement, but I accepted your premise. ODBC and XML are not mutually
exclusive. ODBC is a communications protocol, XML is a "Standard" text file.
You still need the communications protocol to get it from point A to point
B.
<<

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.

>>I think that is an entirely unfair representation of the situation in
companies that use ODBC. First off, anywhere you use the word "ODBC" I'd
substitute "OLE/DB." But beyond that, OLE/DB absolutely allows me to wrapper
my server requests, have flexible programmers and management with a clue.
It's possible to not wrapper in any language, and it's incorrect in any
language. Inflexible programmers are a pain in the ass in any language, and
they exist in all languages. And clueless management is a fact of life! (I'm
management, I can say that <G>)
<<

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

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com