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

----- Original Message -----
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
To: <midrange-l@midrange.com>
Sent: Sunday, November 18, 2001 3:38 AM
Subject: RE: ODBC (was RE: Green screen - it's time is over )


> > -----Original Message-----
> > From: Brad Jensen
>
> I say:
> > The code that defines the ODBC connector is on the client.
The
> > code for the server is on the host.
>
> You say:
> > Well if your database connection is on the web server, and the
> > client is a web browser, your problem is gone.
>
> But in your next email you say:
> > ODBC is client/server.  Without client/server, there is no use
for
> > ODBC.

> You are now just arguing to make sure you don't agree with me.
This
> conversation seems to be reaching the conclusion of its
usefulness.

But the database connection on the web server to the AS/400 can be
ODBC.  (Or OLEDB). Actually your middle server, the NT Web server,
is a client to the AS/400 server. So what you have is client
server/client server. Or client/server(Client /server)

The only probelm that you have identified that resonates with me
is the need to update clients - but I offered a solution to take
care of that.

> > 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.
>
> Did that at the beginning.  In fact, did it years ago.  It's
called
> message-based client/server code.  Nothing to sell.  I actually
do this out
> of the kindness of my heart, hard to believe as that may be.

I've always depended ont he kindness of strangers.

> > > over 85% of the application code WOULD NOT
> > > HAVE REQUIRED A SINGLE CHANGE.
> >
> > Sure, and all the date calculations would have worked fine....
I
> > don't think so.
>
> You're past the point of rational discussion, and now you're
just going to
> disagree with every point, right?

Only the ones that don't seem rational to me.

>  I said 85%.  Do you think more than 15%
> of programs had date calculations?  What would your estimate be?
Actually,
> far less than 15% had date calculations - more had date
COMPARISONS rather
> than date calculations, but even so those were less than 15%.

See, I started as a machine language and assembler program, and I
know that ever comparison is a calculation, so that hair split
went right by me.

Adn you find your programs with date calculations by - reviewing
ever single program.

And date calculations are just one of many changes that would be
necessary - any real data structure changes is likely to cause a
need for a programming change - the program is onlky there to
support the data structure and its use.

> How do I
> know?  My product, Focus/2000, was used to convert hundreds of
systems
> worldwide.

Congratulations.

> > > 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?
>
> Yeah, you're past the point of discussion.  End of conversation.

I'm having a very hard time understanding your flips in logic.
ODBC is bad because it can't do these things, except it can do
these things. ODBC is bad because it requires you to change
programs at a certain level, except they can be changed at the
intermediate server level which can be connected to the host
thru - ODBC.

> > 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?
>
> Final point: I don't have a client/server product, Brad.  I just
design
> architecture, and try to make sure people don't do stupid things
when
> designing systems.

Well I awas about to agree with this when I noticed you suggested
that people do their database access from the AS/400 thru RPGM and
keyed file access, rather than SQL. Why? For speed. But the
argument was for transparent maintainable code a minute ago. If
you do go around moving columns from one data record (table) to
another, its going to be a lot easier to upgrade those programs
with an SQL change rather than a program logic change.