Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!hacgate!ashtate!dbase!awd
From: awd@dbase.A-T.COM (Alastair Dallas)
Newsgroups: comp.databases
Subject: Re: DBASE IV
Summary: INDEX on TRIM() not allowed
Message-ID: <435@dbase.A-T.COM>
Date: 16 Feb 90 05:39:12 GMT
References: <90021021121457@masnet.uucp>
Organization: Ashton Tate Development Center Glendale, Calif.
Lines: 27


Elliot Chapin mentioned a problem with dBASE IV indexes.  He cites
a detailed description of the problem, but the answer is clear from the
first sentence.  You can't index on TRIM(field), because the resulting
key length is indeterminate.  You can do it; it will work for some data
so the system allows the construct, but the results are as indeterminate
as the key length.  In this case, the index code "guesses" how long the
key should be based on the current record's data--for Mr. Chapin, it
seems to guess 21; your mileage may vary.

Lest you think "dBASE is squirrelly to allow such a thing," you should
realize that any dBASE expression evaluating to a data type other than
Logical or Memo is a valid index key expression.  So you can say:

Mvar = "A test string       "
INDEX ON TRIM(Mvar)		&& Key is fixed at 13

USE Foo				&& Contains a field called Name
INDEX ON TRIM(Name)		&& Key length ??, not useful to continue

USE Foo1
INDEX ON 5+3			&& Adds a key (8) for each record in Foo1

dBASE is either extremely squirrelly or extremely flexible, depending
on your point of view.  For my money, it's both :-).

/alastair/