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

["Brad Jensen" <brad@xxxxxxxxxxx>]

> > -----Original Message-----
> > From: Steve Richter
> >
> > Does a logical file on the server, with explicitly declared
flds, used as
> > the target file name of the client's odbc calls,  solve the
column name
> > dependency concerns?
> >
> > Dont know much about ODBC, but if the odbc connection info (
actual target
> > system, library and file name ) can be stored external to the
client pgm,
> > would that satisfy the "client code is dependent on the target
> > file name and
> > location" objection?
>
> Perhaps, and perhaps.  I am not saying that all ODBC is bad; I'm
saying that
> it's more susceptible to changes in the database layout than a
server-based
> environment.  That doesn't mean you can't avoid some of the
problems with
> stringent coding guidelines and clever techniques.
>
> The fact is that you can write perfectly good code using just
about any
> language, provided you have some strict guidelines in place.
Believe it or
> not, you can write flexible, maintainable code in assembly
language.

And as long as your health holds out, you can maintain it.

I'm in a business group with a guy who is looking for a mainframe
assembler programmer, preferably under 60.

>  While
> you've pointed out a couple of ways to insulate the ODBC
programmer from
> changing database characteristics, what percentage of ODBC
access is written
> that way, do you think?  My guess is that the overwhelming
majority is not.
>
> But each guideline adds its own complexity as well.  How do you
store the
> "external connection definitions"?  How do you access them?  How
do you make
> sure that all your clients are getting the same definitions?
Are they
> stored on the host?  Which host?  As you start adding layers of
complexity,
> the "ease of use" of ODBC evaporates and make the client/server
approach
> even that much more appealing.

ODBC is client/server.  Without client/server, there is no use for
ODBC.

> And even with all the additional work required, this "enhanced
ODBC"
> approach only solves some of the problems.  Take a look at my
earlier post,
> where I outline a simple, real-world situation where shipment
information
> was moved from one level of the hierarchy to a new level.  A
server-based
> architecture takes this in stride much better than an ODBC
architecture.

I can't imagine it would, if the presentation layer is displaying
this quantity in the detail line, and it is suddenly not there.