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

> Not if your client relies on knowledge of the table and column names of
your
> database!  That's the point of the entire discussion.  If the client is
> dependent upon field names, it is tied to your database, and more
> importantly, your database is tied to your client.

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?

Steve Richter


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


> > -----Original Message-----
> > From: Brad Jensen
> >
> > > This ability to change the underlying physical layout
> > (including, for
> > > example, the fact that a file is physically moved to another
> > machine, or
> > > even another data format entirely) is the primary reason that a
> > > message-based architecture is so preferable to ODBC.
> >
> > This must be peculiar to IBM's ODBC for the AS/400. It's totally
> > unfamiliar to me.
>
> If you use ODBC and change the name of a column, the ODBC doesn't work.
> This is the same on any ODBC implementation.  You can avoid the issues to
> some degree on a query you use a "SELECT *", but we've discussed the
various
> reasons why that is bad programming practice.   Regardless, to identify
> JOINs, ORDERs and so on you need to know the column names.  The point is:
> changing column names breaks ODBC calls.
>
>
> > Well ,it seems to me that with programming you can decouple the
> > data representation at any level you choose.
>
> Not if your client relies on knowledge of the table and column names of
your
> database!  That's the point of the entire discussion.  If the client is
> dependent upon field names, it is tied to your database, and more
> importantly, your database is tied to your client.  By decoupling the
client
> and the database through an intermediate messaging interface, you thereby
> remove the dependence of one upon the other, and allow changes to occur in
> one region that do not affect the other.
>
> This is the basic premise behind tiered programming.
>
> 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.
>
>