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

["jt" <jt@xxxxxx>]

Joe, Brad

I believe this is the premise of Rob Dixon's Erros.  This is a product that
has been available for years, but which hasn't quite caught on, as yet.

There are a huge multitude of ways, to skin this cat.  Some more effective,
some less...  Some catch the fancy of the iSeries Community, some don't.
Most of these don't even catch the eye of the computer industry, however.

But that sure doesn't necessary mean they aren't viable options...!
Marketing does play a HUGE part, because perception is one of the key
elements of the success of any product.  But marketing, in no way,
determines what is actually the best fit for any given business, IMV.

jt


"Have a GREAT day...!  And a BETTER ONE TOMORROW~~~:-)" (sm)


> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Joe Pluta
> Sent: Saturday, November 17, 2001 10:03 AM
> To: midrange-l@midrange.com
> 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