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

> -----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.


> 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.

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.

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.


> 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.


> 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.  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.

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

> > 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


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.


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.

Joe Pluta
www.plutabrothers.com