Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!sun-barr!apple!usc!elroy.jpl.nasa.gov!jato!herron.uucp!jbrown
From: jbrown@herron.uucp (Jordan Brown)
Newsgroups: comp.databases
Subject: Re: Avoiding SET FILTER TO command
Message-ID: <107@herron.uucp>
Date: 2 Aug 89 09:27:52 GMT
References: <9636@phoenix.Princeton.EDU> <472@uncmed.med.unc.edu> <104@herron.uucp> <61@cica.cica.indiana.edu>
Reply-To: jbrown@jato.jpl.nasa.gov
Lines: 26

mr@cica.cica.indiana.edu (Michael Regoli) writes:
> jbrown@herron.uucp (Jordan Brown) writes:
> 
> >The real answer is to index on the pair of fields and seek on the
> >concatenation.
> 
> >index on last+first to lf
> >seek "Brown           Jordan"
>             ^^^^^^^^^^^
> why is there whitespace between first and last names?  is this a
> tab?

I wondered if I should explain that further.

Remember that dBASE (and most dBASEoids) uses fixed-width fields.
The "last+first" that you're indexing on will include the trailing
spaces from the "last" field (and those from the "first" field, but
those are less important here).  When you go to do the seek, you have
to build a key that matches this pattern.  (Typically you would do
this by having the GET be that long when you ask the user for the
value.)  My example has a (um, 1 2 3 ... 16) 16 character "last"
field.

The indexing code in dBASE doesn't "know" that you're playing with
two fields.  It just sees one long string.  When you do the seek,
you better give it a string that looks similar.