Geoff and Others:

I agree with your point, in the case of a VARCHAR it should remove
the whitespace at the right, by default and in the case of a CHAR
field, the default should be to return the field without trimming.
In both cases this should be user modifyable to some other form of
trimming.

Forget the BDE, what the BDE does with different pieces of data, is
of no consequence. The BDE is not always correct in it's actions, do
we want to emulate the BDE or do things the way the BDE shoud do
them, if it wasn't broken?

Think of it this way, say it's a large organization, and the DBA
designed the tables, after 4 days of meetings with the end-user, and
SA. The programmer was not priviledged to those meetings, they just
got a 17th generation barely readable photo-copy of the CREATE
statements. After a 15 minute meeting with the SA at 5:30 on a
Friday afternoon, when their wife phoned at 4:30, saying she was "in-
the-mood" and to hurry home.

What does the DBA's use of CHAR and VARCHAR tell the programmer? It
tells the programmer that a CHAR is a fixed length field, and VARCHAR
is a variable length field.

Paul

On 22 Mar 2001, at 22:32, Geoff Worboys wrote:

To: <IBObjects@yahoogroups.com>
Organization: Telesis Computing
From: "Geoff Worboys" <geoff@...>
Date sent: Thu, 22 Mar 2001 22:32:46 +1100
Send reply to: IBObjects@yahoogroups.com
Subject: Re: [IBO] ib_query ignores my data!

> > We are probably at the point of personal preferences now.
>
> You are probably correct that this is very much a personal preference,
> but I would like an opportunity to argue the point just a bit longer -
> perhaps I may persuade you :-)
>
>
> > It is a generally accepted design principle that you should
> > not change a users data without warning, unless you apriori
> > know what the form the data should be.
>
> My answer to this is that I do know that in _almost_ all text fields
> of every application I have written that trailing whitespace (and
> often leading whitespace) is undesireable. If IBO were not removing
> it by default, I would be removing it - without warning to the user,
> just as many fields up sent to uppercase without asking the user.
>
> Where whitespace is desirable I make a point of using CHAR.
>
>
> > Example: Suppose an unusual encryption scheme allows right spaces in
> > a CHAR field. A default position of trimming ruins it.
>
> Unless you are encrypting field-by-field, every field in the database
> (which does not seem a very efficent way of operating), then the
> occassional encrypted field can either be setup as CHAR - or if that
> is inappropriate disable trimming on that field.
>
> To my mind, the exceptions should not be used to make the rule.
> Rather it is the majority requirement that controls the default, and
> the exceptions should be handled specially. For example; When I
> design components I setup the default that seems to be the value most
> commonly required. I dont set it to a value required for only two
> component instances - requiring that I specifically set the value on
> every other instance.
>
> I guess that spaces in character fields may be the standard
> requirement in a scientific application. I can only go by my own
> experience in business systems where I have perhaps one or two domains
> (if that) in any given application where trailing spaces might be
> considered significant.
>
>
> > However, a developer can use the component no matter what the
> > default setings are.
>
> Components for Delphi are there for the developer NOT for the user.
> Delphi is supposed to be a RAD - emphasis on RAPID application
> development environment. The defaults supplied within Delphi
> components try (not always successfully) to speed development by
> providing defaults appropriate to the majority of applications. It is
> still upto the developer to decide what is correct for their
> particular application - and if desired they can derive their own
> components from the existing to change the defaults (thats what I
> generally do anyway).
>
>
> Some points to consider...
>
> * We are talking about defaults not the only action available.
>
> * I am proposing that we set up the defaults that seem consistent with
> the SQL data type definition.
>
> * Provided it is documented it should not be too much of an issue (one
> way or the other).
>
> * Changing the default totally away from trimming now would be likely
> to break existing applications.
>
> * Unless my experience has led me astray, the vast majority of fields
> in the vast majority of applications consider trailing spaces to be at
> least redundant and possibly even a potential cause of problems.
>
>
> I hope this does not come across too strongly. The issue is not that
> important, at least to me, since I have my own derivatives where I
> change defaults to suit myself.
>
> Geoff Worboys
> Telesis Computing
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-~> Do you have 128-bit SSL encryption server
> security? Get VeriSign's FREE Guide, "Securing Your Web Site for
> Business." Get it now!
> http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/P0AVlB/TM
> ---------------------------------------------------------------------_
> ->
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>


Paul Schmidt,
Tricat Technologies
Email: paul@...
Website: www.tricattechnologies.com