Subject Re: [IBO] ib_query ignores my data!
Author Geoff Worboys
> 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