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: Saturday, November 17, 2001 8:56 AM
Subject: RE: ODBC (was RE: Green screen - it's time is over )


> > -----Original Message-----
> > From: Brad Jensen
> >
> > I have no idea why you would want to change the names of
columns,
> > I would think that would be very poor programming practice, if
you
> > mean the names of columns in tables. It will sure be a
surprise to
> > the other people trying to access the database if you do.
>
> In the real world, though, column names do change.  Files are
moved to other
> libraries.  Data is moved to another machine.

So you change the ODBC connecter. You are going to have to change
something somewhere.

If this is a frequent occurance, you have one odbc connection that
contains a table of the other connections.

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.

> Fields are moved from one
> file to another.

It seems to me that this is going to cause a need for a change in
program logic in most access to the data any ways.

> As you say, changes to your database require every program
> that relies on the database layout to be changed.

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.

> That's the reason I
> recommend that only one program (the server) understands the
layout of the
> data.  That way, database changes have a minimal effect on the
rest of your
> application.
>
>
> > Create new tables, columns, indexes
> > Populate the rows with data
> > Delete and modify column structures
> > Run most any sort of sql
> > Create stored procedures
> > Execute stored procedures with parameters
>
> With the possible exception of executing a stored procedure, I
would never,
> ever want a client program to do any of these things.  There's
simply no
> reason for it.  The only things that should ever touch my data -
and
> especially my schema! - are programs on my server under my
control.  If I
> open this up to the client, any rogue program could
theoretically break in
> and attack my data.

I don't understnad. Why are you complaining that ODBC can't do
those things?

> Anyway, you and I have slightly different views of things.  Mine
comes from
> dealing with clients calling up in the middle of the night
because some
> operator deleted their data without backing it up.

I don;t understand this sort of argument. I did my first
programming with toggle switches. I used to walk to and from
school in the sleet in July uphill both ways. Actually I did do my
first programming with toggle switches, and had to wire together
shift registers to pass the class. Actually the school was uphill
both ways, I lived halfway up one side of a hill that it was at
the bottom of the other side of. You couldn't walk around the
bottom of the hill - because there were other hills in the way.

> I have seen companies
> literally go bankrupt because of loss of data. Those companies
are going to
> be a bit mroe sensitive to the idea of data access, and less
amenable to the
> concept of allowing a client program to delete columns of data.

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.

> > And most importantly,
> >     understand what is going on when you read the code

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

I understand you see a value in a server dealing with the
database, and I do too.

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.

Brad Jensen
ESC