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

----- Original Message -----
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
To: <midrange-l@midrange.com>
Sent: Saturday, November 17, 2001 12:47 PM
Subject: RE: ODBC (was RE: Green screen - it's time is over )


> > -----Original Message-----
> > From: Brad Jensen
> >
> > So you change the ODBC connecter. You are going to have to
change
> > something somewhere.
>
> The code that defines the ODBC connector is on the client.  The
code for the
> server is on the host.  Changing one program on the host is
better than
> changing the many client applications that implement the ODBC
connector, for
> a number of reasons ranging from amoutn of work to
synchronization.  If
> you've ever tried to get 100 end users to simultaneously upgrade
their
> software, you must understand the difficulty.  This is the
fundamental
> argument of distributed design.

Well if you database connection is on the web server, and the
client is a web browser, your problem is gone.

> > As far as the column names changing, you are going to have the
> > same trouble with a server program that uses the column names,
it
> > will have to be changed. I'm trying to think of any
justification
> > for changing a column name in a production environment, and I
> > can't think of one. Even if you have a magic server that can
guess
> > the new name, all the other applications that point to it,
such as
> > local RPG programs or queries, are going to be broken.
>
> I've worked in software development for quite a few years now,
and during
> that time I've seen many occasions where column names change (a
typical
> instance is when two applications are merged and there are
collisions), or
> data attributes are moved from one file to another (one case in
particular
> was when we added partial shipment records to order entry).  You
can argue
> all you want that it doesn't happen, but in the real world, it
does.  And if
> your design can handle it, your system is far more flexible.

If you merge your applicaitionns you better review all your client
code.  If you thinnk your client is safe because it doesnt care
about column names, you are living with false assurance.

> By having a single server accessing the data, only that server
changes.
> Again, this is the fundamental point that I seem to have
difficulty getting
> across.  If you encapsulate your data access in one place,
database changes
> have far less impact on your applications.  In many cases, they
have none.

Well, actually the impression you are giving me is that you are
attacking straw dogs trying to get us to ask what your wonderful
answer to all this is.

> For a real world example, take the Y2K problem.  Had systems
accessed their
> data through server programs, over 85% of the application code
WOULD NOT
> HAVE REQUIRED A SINGLE CHANGE.  That's because, in reality, most
programs
> would have continued to work just fine with a 6-digit date, if
the data were
> returned to them in the correct order.  We could have expanded
the date
> fields in the database, but the server could have returned
6-digit dates to
> the application programs.

Sure, and all the date calculatiosn would have worked fine.... I
don't think so.

> > Well, I still don't understand the idea that the program
relies on
> > the database layout.
> >
> > If you mean it relies on the fact that a certain column is in
a
> > certain table, sure. If that clumn moves to another table, the
> > underlying structure and meaning of the data has changed also,
and
> > I want the old program built on the changed assumption to know
it
> > and say there is an error.
>
> This simply isn't true.  Let's take the example of the partial
shipment
> record.  The attribute of "total quantity shipped" for an order
was
> originally stored on the order detail line.  Then, due to the
database
> change, the total quantity shipped was now a sum of the values
on the
> individual partial shipment records.
>
> For an ODBC environment, you would have to change EVERY SINGLE
program that
> had an ODBC call that accessed the total quantity shipped in the
detail line
> to do a JOIN on the shipment detail and a TOTAL of the the
shipped quantity.
>
> In a server environment, you could simply change the server.  It
would
> perform the totalling internally, put the total quantity shipped
in the
> original field of the message, AND NO APPLICATION PROGRAM WOULD
CHANGE.

OH MY GOODNESS.

Only people are already doing that by putting the logic at the web
server level, so what's the big deal?

You are still changing all the programs that accessed that
information, you have just moved the logic and your client isn't
really a program, it is just a display.  A person could point to
the AS/400 with the green screen, and say they are doing the same
thing by having the RPG program talk to the workstation handler,
which has software running in it to run the screens.
A green screen is just a very studpid web browser - it's a
hardware based client.

> > hey, I was responding to your complaint that ODBC couldn't do
> > certain things. I didn't say I wanted it to do those things. I
> > don't understand why you would complain that odbc can't do
> > something, then when I point out it can, you ridicule the
notion
> > of doing it.
>
> I never said anything about ODBC's capabilities.  I talked about
it's
> SUITABILITY (or, in my opinion, its lack of suitability) for
client-side
> programming.

See archives,

> My argument:
>
> Client-side knowledge of the database makes implementing
database changes
> more difficult than message-based server programming.  True or
false?  ODBC
> requires client-side knowledge of the database.  True or false?
If you
> answer both "True", then what follows is my initial assertion
that ODBC is
> less flexible than message-based programming in handling
database changes.

No, actually ODBC is more flexible (in terms of what can be done
at the client end) but it is less secure and a little less
elegant.

By the way, you can get rid of the problem of updating all those
client machines very easily. Make your client an activex control
hosted on a web page in the web browser, using IE. Every time you
change the program, your activeX downloads and updates your PC.

> I said nothing more, nothing less, and I think the statement
still stands.

Then I wonder whose statements I was responding to, I thought they
were yours. My mistake.
>
> > > Readability is in the eye of the beholder.
> >
> > Yes, that's exactly correct, and you want a program that can
be
> > understood by a beginner, not an expert.
> > Programs should be easy to develop, easy for others to
maintain,
> > and robust. The old jokes is, that like easy fast and cheap,
you
> > can have two out of three.
>
> It is no more difficult to understand server-based code than
ODBC code.
> Which of the following is more readable?   Which is more
maintainable?
>
> int remaining =
server.getOrder(ordernumber).getQuantityRemaining();
>
> or the following:
>
> SELECT SUM(ODQORD) - SUM(OSQSHP) INTO :REMAINING FROM ORDDTL,
ORDSHP WHERE
> ODORD = :ORDERNUMBER AND ODLINE = :LINENUMBER AND ODORD = OQORD
AND ODLINE =
> OQLINE

You are doing the same logic, you are just doing at the
intermediate server level. Plus you have now added another program
that you have to write and debug. And of course you could write
the client with the same code if you moved the logic to a c;ass
module on the client. Big deal.

> With the server approach, if the database changes again (let's
say we start
> tracking returns in a third file), I change only the server
program.  My
> server-based application code remains the same.  On the other
hand, with the
> ODBC approach, the client code changes as follows:
>
> SELECT SUM(ODQORD) - SUM(OSQSHP) + SUM(ORRET) INTO :REMAINING
FROM ORDDTL,
> ORDSHP, ORDRET WHERE ODORD = :ORDERNUMBER AND ODLINE =
:LINENUMBER AND OQORD
> = ODORD AND OQDLINE = ODLINE AND ORORD = ODORD AND ORLINE =
ODLINE
>
> Heck, I don't even know if this works.  I'm not sure you can
join two
> secondary files to the same primary file and expect proper
results.
> Instead, you may have to add a separate SELECT INTO.  In any
event, this has
> to change in EVERY client that currently uses the total quantity
shipped,
> whereas with the server approach, only one program changes.
Because they
> work directly in SQL syntax, the ODBC programmer has to be not
only an
> expert in SQL, but also in the layout of the database, whereas
the
> server-based application programmer simply needs to know which
server to
> invoke.

Well, that seems pretty silly to me. If you are worried about
knowing SQL, you take the wizard who was writing the server
program, have him create class modules that the client programmer
can use. Or you can just fire the client programmer, since you
won't need him, and let your server guy write the client code.

> If this post doesn't convince you of the validity of separating
client-side
> application programming from the details of the database, then
we may just
> have to agree to disagree.

It seems to me that you could use some more credible reasons for
promoting what you are talking about - like speed and security,
and the fact that you are writing to a screen population that
numbers in the tens of millions - web browsers. You don't have to
do any hairsplitting to prove that - and you don't have to argue
with anyone or convert them.

Okay, please tell us about your wonderful solution. I thought it
wasn't a server , I thought it was middleware on Intel between an
AS/400 server and a client. Not so?