At 2001-03-23 12:12 +1100, "Geoff Worboys" <geoff@...>
wrote:

>David,
>
> > Although IBO is not to blame (because we weren't using it
> > then, and the RDBMS wasn't InterBase), we have had a lot
> > of trouble with databases or database components munging
> > our spaces, and had to resort to wrapping ".AsString"
> > calls with a kludge like "FixDBStr".
>
>Do you mind describing the situation a bit more? This sounds
>interesting thats all.

Well, interesting is what it isn't, but I guess I can put you out of your
misery.

>I have come across so few instances where
>spaces are truly significant that I am curious.

If systems designers knew beforehand that one day using spaces for anything
significant would give them grief, they probably would think twice about
doing it. So, it is probably correct to say that any given situation in
which spaces are used could probably be altered so that the issue goes
away. In any case, as you say, most people doing every-day things will
probably get by quite nicely, never realising that their spaces are being
trimmed off for them (i.e., the spaces are not significant).

Unfortunately, certainly in my case, people sometimes have to deal with
systems that have already been designed, and input data and interface specs
that they have no control over.

In my case, we have to deal with (a) an old system design, dating back to
pre-history and flat-file days, in which nearly every column is a fixed
length CHAR, and even VARCHAR columns, of which there are still a fair
number, hold fixed length records (but maybe of different types, hence the
varying length); (b) an archaic communications standard in which all fields
are fixed width and blank or zero padded (which does compress nicely,
though). The communications standard in fact influenced the system design,
although, of course, that was not a necessary consequence.

Now we have to live with it. It's a big system, and probably not worth the
effort to change it. Certainly, we could trim and pad, trim and pad our way
through every I/O operation, but why bother? At this stage, it would just
introduce another source of error (oops, forgot to pad here, didn't trim
there).

>For example; I have used characters and codes (sort of like boolean
>but with lots more options). However I always found it was more
>practical to avoid spaces in such flag sets, not only to avoid string
>mangling but also for visual feedback. And I dont just mean for the
>user, but also for myself as the developer. I like to be able to SEE
>when a field contains something (is not NULL) even when just browsing
>the database and the best way of doing this was always to avoid
>spaces.

Sure :-) with hindsight! And with free choice. In the case of dealing with
certain givens (as mentioned above), it is sometimes more prudent just to
"go with the flow" and simplify program logic, minimising sources of error.


Cheers,

David Trudgett