> How many specific examples of where spaces are important need
> to be pointed out?

Just enough to prove that spaces are significant in the majority of
applications and the majority of fields in those applications.

Please remember we are talking about development defaults here, not
something that cannot be changed by the developer to suit the specific
application.

> Communications applications that demand space padding (the
> designer may choose to store raw comms data in the database).
>
> Encryption applications, which may generate spaces in the
> output (even at the end!)
>
> Arrays of flags, where a space signifies 'default' (just don't
> default the last one!)

Find use CHAR or specify no trimming on these particular fields.

> You may not do these things yourself, but people out there do, and
> these people sure won't be happy about forced (or even default)
> trimming of spaces.

I do not understand why any developer should be unhappy with defaults
that dont suit. Just derive your own variations and change the
defaults. It is my strong opinion and any serious application
developer should do this as a matter of standard practice. It helps
protect you from undesired changes to the base code and makes
development more RAPID.

Of course this applies to myself as well. Which is why I do not care
too much which way this actually goes. My only concern is that for
less experienced developers the defaults should follow the most common
requirement. And while I could be wrong that trailing spaces are
redundant in most fields, this is what my experience tells me.

It seems to me that treating spaces as significant is a game for
experienced developers - and certainly not anything that will be
presented directly to the user. They are not visible which makes the
term GUI rather pointless. Why bother with a graphic interface if the
user cant see the data.

> Just remember the cardinal rule: don't mess with people's data!

Actually the cardinal rule in business systems, is to stick to the
business rules. Most of the business rules for my applications
dictate that trailing spaces are a bad thing - if the user cant see
it, they dont know its there. If they dont know its there and it can
cause problems, then its another call to the support desk. Business
applications make a point of messing with peoples data. We force it
to uppercase, format in particular ways, round floating point values
etc etc etc.

I do agree with you with regard to Interbase itself. It is a generic
DBMS and may be used for all sorts of data. But IBO is a development
tool designed for RAD. As such it makes certain assumptions to try
and help with RAPID development. This is true of all such libraries.
If you dont like what they do, change it.

> You can't _assume_ you can change data just because you
> psychologically think of a space character as different from
> any other character. It definitely isn't!

A trailing space very often is different. It is not visible (it could
be a null character for all the user knows). This can make the data
quite misleading.


All in IMHO :-)

Geoff Worboys
Telesis Computing