× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



You're right, it's turning religious.  If a programmer can be trained to use
your call interface, they can be trained to call a server object.  If you
exclude SQL syntax from your ODBC requests, it's not ODBC, it's just program
calls.

As a personal hiring matter, if someone came to me and proved that they had
a ton of experience developing platform independent message-based
client/server architectures, I'd hire that person over an ADO expert in a
hot minute.  For all I know, the ADO experts may end up on the same pile as
all the LotusScript experts someday.  But a programmer who can learn, use
and extend new systems and architectures is worth her weight in gold.

Because ADO is a different issue.  ADO is not ODBC.  ADO is Microsoft
proprietary, as is OLE/DB, so when you use either, any portability benefits
of SQL evaporate.  I'm much more interested in my clients being platform
independent than my servers, and tying myself to proprietary Microsoft APIs
is antithetical to a platform independent architecture.  If you're tied to
ADO, then you have already decided most of your architecture in advance, and
this discussion is moot.  I tend more towards the platform independence of
servlets and a Java-centric approach, so that may be where we differ.  Any
proprietary code in my systems I want to write myself, thank you very much.

And sending XML via an ODBC field simply makes no sense to me.  Shoehorning
XML through the funnel of ODBC sounds like the man who only has a hammer -
everything looks like a nail.  Or like a Microsoft API.

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 12:50 PM
> To: 'midrange-l@midrange.com'
> Subject: RE: IIS to as/400 odbc
>
>
> 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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.