RE: ODBC (was RE: Green screen - it's time is over )

OK, I'm totally confused then. How can you have ONE (as in 1, uno, single,
less than 2) program that handles ANY and ALL interaction with a file? It
handles updates? Inserts? Deletes? Queries (get price, get description, list
items where price < 100, etc.) Man, that must be one hell of a program. Any
chance you could post a small one so we can see that?

-Walden

------------
Walden H Leverich III
President
Tech Software
(516)627-3800 x11
WaldenL@TechSoftInc.com
http://www.TechSoftInc.com



-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: Saturday, November 17, 2001 8:05 PM
To: midrange-l@midrange.com
Subject: RE: ODBC (was RE: Green screen - it's time is over )


> -----Original Message-----
> From: Walden H. Leverich
>
> You believe that the CLIENT shouldn't have knowledge of the physical
> layout of the database, no? However you don't seem to accept the idea
> that all ODBC
> doesn't have to be done from the "client".

The conversation was about VB and ODBC, which is client-side ODBC.  In fact,
I think I used the phrase "client-side" about a dozen times in my posts. So,
for that particular conversation the whole thing was about ODBC on the
client.

On the other hand, while I don't mind SQL on the host, I see no reason to
use ODBC on the host.  Embedded SQL performs better but has the same power,
unless I'm mistaken.


> ODBC is not "more susceptible to
> changes in the database layout than a server-based[1] environment" in
> fact I'd argue it's less. I assume you're writing your server-based
> programs in RPG (or COBOL) using native I/O. If you want to add a
> field (the MOST common database change) you will have to recompile
> EVERY program that accesses that
> file. On the other hand, using SQL and ODBC, you won't.

I don't seem to be getting my point across here.  By definition in a server
based system, only ONE program, the server program, accesses the file.  In
that environment, only the single server program that accesses the file
needs to be recompiled, whereas with ODBC or even SQL, any statement that
directly accesses the affected field must be updated.  So, your comment
about "EVERY program that accesses the file" reduces to ONE program.  Do I
make myself clear on this?


> Don't confuse the use of ODBC with the idea of placing data access on
> each users desktop. First, user desktops can use message-based
> architecture to talk to a PC server, that server could use ODBC to
> talk to the AS/400.

Yeah they could.  Now you have the worst of both worlds: the overhead of
messaging and the overhead of the ODBC layer.  Why not simply send the
message directly to the AS/400?  Why include the middle layer of ODBC?


> Second, if you haven't noticed, thick-client C/S programming is dead,
> we are moving to a server-based architecture again, it's called a
> web-server. If you've isolated your DB access to that server (or an
> app server) you don't have "to get 100 end users to simultaneously
> upgrade their software." All you need to do is change the code on the
> server.

Unfortunately, thick clients are not yet dead.  People are still writing
VB/ODBC solutions and marketing them as "business solutions", which I
believe is wrong.  ODBC on the client happens all the time, and that's what
I was arguing against in my previous post.

On the other hand, some people are embedding ODBC calls in their servlets
via JDBC.  This is a little less painful from an impact of change standpoint
but still wrong, for a somewhat different reason.  If your data access is
host-centric, you may as well embed your SQL in your host programs for
performance rather than leave them as interpreted ODBC statements.  I admit
I haven't done the benchmarks for this particular situation, but I have to
believe that embedded SQL outperforms ODBC for everything.  You disagree?

So, the way I look at it:

1. If you have twenty different servlets that all access the same data via
different SQL statements, that's just plain wrong.

2. If your SQL is embedded in a single Java class and accessing your host
via JDBC, that's less wrong, but there's still the performance hit of the
ODBC interpretation layer.

3. If your class accesses data through a message-based server that uses
embedded SQL, I think you have the best performance for an SQL based
approach.

However, once you've moved to message-based embedded SQL, you may as well
write programs that take advantage of the database.  As I've shown numerous
times, for most transaction-based needs, native I/O outsrips SQL easily.  So
why use SQL at all for situations where it doesn't perform?

Anyway, this horse is dead.  It's glue factory.  I can't explain my
positions more succinctly than this.  If, after reading these posts, you
still think ODBC has a place in missions-critical application development,
then by all means have at it.  I just hope you don't introduce it at any of
my client sites...

Joe Pluta
www.plutabrothers.com

_______________________________________________
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
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.