[comp.sys.ibm.pc.misc] Clipper - SET EXACT <on/off>, SEEK

v067qklp@ubvmsb.cc.buffalo.edu (Danielle T Mazzotta) (12/02/90)

Just a quick question for a friend regarding Clipper:

   Does SET EXACT <ON/OFF> work as it does in DBASEIII+ or has
   it been found to be buggy at all?  Do all the routines respect
   that flag?  He's (my friend) getting frustrated complaining that
   even with EXACT ON, SEEK is setting FOUND() to true even when
   an exact match hasn't been made (e.g. lengths are different).


			Thanks in advance,

				--Danielle

tleylan@pegasus.com (Tom Leylan) (12/03/90)

In article <48680@eerie.acsu.Buffalo.EDU> v067qklp@ubvmsb.cc.buffalo.edu writes:
>Just a quick question for a friend regarding Clipper:
>
>   Does SET EXACT <ON/OFF> work as it does in DBASEIII+ or has
>   it been found to be buggy at all?  Do all the routines respect
>   that flag?  He's (my friend) getting frustrated complaining that
>   even with EXACT ON, SEEK is setting FOUND() to true even when
>   an exact match hasn't been made (e.g. lengths are different).
>
Danielle,

I guarantee that Clipper's SEEK isn't buggy and don't know if it follows
dBASE III to the letter but I believe so.  The fact is that SET EXACT has
no effect on a SEEK.  SET EXACT is only used in comparisons and my general
rule is to SET EXACT ON at the beginning and leave it that way.  One does
not want to wonder about the switch setting when comparing two strings.

The reason that your friend <it's always a friend isn't it (just kidding)>
is finding the record is most likely that they are trimming the key.  The
comparison is made up until the SEEK key is exhausted and at that point
you have a match.  Keep the length of the variable being SOOKEN (some sort
of perverted future-tense of SEEK) the same length as the field in the
index expression.

Note (not that you asked) that SET SOFTSEEK can be switched on and off to
alternatively set you at the correct record (if present) or at the next
record beyond the key (if not present).  An alternative if you want to
put the user "close".

As a parting note, I prefer to trim the SEEK string when the user has
keyed it in since they may not know the entire name and that allows them
to type up until they aren't sure.  In a process of some sort that wouldn't
be advisable of course so just use my padding suggestion.

tom leylan
former Senior Systems Analyst - Nantucket Corporation

marwk@levels.sait.edu.au (12/04/90)

In article <1990Dec3.062351.11886@pegasus.com>, tleylan@pegasus.com (Tom Leylan) writes:
> In article <48680@eerie.acsu.Buffalo.EDU> v067qklp@ubvmsb.cc.buffalo.edu writes:
>>Just a quick question for a friend regarding Clipper:
>>
>>   Does SET EXACT <ON/OFF> work as it does in DBASEIII+ or has
>>   it been found to be buggy at all?  Do all the routines respect
>>   that flag?  He's (my friend) getting frustrated complaining that
>>   even with EXACT ON, SEEK is setting FOUND() to true even when
>>   an exact match hasn't been made (e.g. lengths are different).
>>
> Danielle,
>
> I guarantee that Clipper's SEEK isn't buggy and don't know if it follows

Are you being paid to make this claim?  Just kidding.

> dBASE III to the letter but I believe so.  The fact is that SET EXACT has
> no effect on a SEEK.  SET EXACT is only used in comparisons and my general
> rule is to SET EXACT ON at the beginning and leave it that way.  One does
> not want to wonder about the switch setting when comparing two strings.

In order to perform the SEEK a comparion of two strings is indeed made.
I have tested the SEEK and FIND commands with dBASE III and the SET EXACT
command does not affect it though.

> The reason that your friend <it's always a friend isn't it (just kidding)>
> is finding the record is most likely that they are trimming the key.  The
> comparison is made up until the SEEK key is exhausted and at that point
> you have a match.  Keep the length of the variable being SOOKEN (some sort
> of perverted future-tense of SEEK) the same length as the field in the
> index expression.

In fact 'being SOOKEN' is an attemp to use the PASSIVE tense!
SOOKEN should be replaced by SOUGHT.  Gone are the days when children
learnt about their language - Using SOUGHT does not put the sentence into
the past tense, but somply makes it passive.

>
>
> tom leylan
> former Senior Systems Analyst - Nantucket Corporation

Ray
former cub

tleylan@pegasus.com (Tom Leylan) (12/05/90)

In article <15730.275aa66e@levels.sait.edu.au> marwk@levels.sait.edu.au writes:
>
>In fact 'being SOOKEN' is an attemp to use the PASSIVE tense!
>SOOKEN should be replaced by SOUGHT.  Gone are the days when children
>learnt about their language - Using SOUGHT does not put the sentence into
>the past tense, but somply makes it passive.
>
>Ray
>former cub

I'm sort of a believer in English evolution by general usage and was merely
attempting to worm "sooken" into the language.  I remain unfamiliar with
your use of the Old English "somply" however... <heh, heh>

BTW, I notice that you are in Australia.  Anywhere near Sydney ?  I'll be
"one of the featured speakers" (according to the advertising literature)
at the Clipper Developer's Conference in Feb. 1991 (25th - 27th)

tom