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

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> -----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.  Fields are moved from one
file to another.  As you say, changes to your database require every program
that relies on the database layout to be changed.  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.

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


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

Readability is in the eye of the beholder.


Joe Pluta
www.plutabrothers.com