Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!jato!herron.uucp!jbrown
From: jbrown@herron.uucp (Jordan Brown)
Newsgroups: comp.databases
Subject: Re: Clipper/dBase Seek Question
Message-ID: <117@herron.uucp>
Date: 25 Aug 89 21:09:37 GMT
References: <238@fltk.UUCP> <20900014@silver> <202@dbase.UUCP>
Reply-To: jbrown@jato.jpl.nasa.gov
Lines: 22

In article <202@dbase.UUCP>, awd@dbase.UUCP (Alastair Dallas) writes:
> INDEX ON LTRIM(..) is a bad idea.  It is very important that index keys be
> fixed length, and TRIM() or LTRIM() do not support this:
> ...
> Indexes must have fixed length keys.  Quoting the dBASE IV manual (p2-150):
> "dBASE IV does not prohibit you from creating an index with a variable-length
> key, but the index may not be reliable."

Gee, we thought that one of the improvements of dBASE III over dBASE II
was that you could have TRIMs in the index expression.
(That's half of what all that horrible code in the parser is there for -
to calculate the maximum possible length of the expression for use in
sizing index keys.)

There certainly were cases where this didn't work right - where it
couldn't figure out the right maximum - but TRIM wasn't one of them.

Clipper has a no-TRIM restriction on indexes, so avoiding TRIM is
a good idea.  Theirs reason is that to calculate the length of an
index key they evaluate it on a blank record; the resultant length
is used.  Obviously TRIM will return a somewhat smaller value for
blank fields than for filled fields.