Getnext lookup -

[Kenneth Brody]

Quoting Nancy Palmquist (Thu, 04 Dec 2008 14:29:10 -0500):

> Kenneth Brody wrote:
>> Quoting Nancy Palmquist (Thu, 04 Dec 2008 11:53:36 -0500):
>>
>>> Walter Vaughan wrote:
>> [...]
>>>> ::pn(10,,g)=upd(1):
>>>> ::lookup -  k=pn   i=b -nx:
>>>> :1 ne pn:show "@No match for "<pn; goto loopU:
>> [...]
>>> Remember if 1="BigPart" and pn eq "BIG" it will find that part of   
>>> no  other part name starts with BIG.
>>>
>>> And you test 1 ne pn would not catch that difference.
>>>
>>> 1{"~" ne pn{"~" would test true when they are identical and false   
>>>  when they are not.
>>>
>>> Any silly character that is never in pn would work.
>>
>> In this particular case, since pn is defined as (10,,g), the above steps
>> aren't necessary, as pn won't be "BIG" but rather "BIG       ".  As such,
>> it would not match "BigPart   ".
>>
>> In cases where you don't have a fixed-length field, such as using the
>> import's field upd(1) directly, then your advice is correct.
>>
>
> That is not supported by my experience with filepro.  You would have to
> set the environment variable that tells it to match the full field to
> make sure that happens and that changed the existing behavior for many
> people.

I believe that you may be thinking of browse lookups, where the default
behavior is to have trailing spaces in the key not significant.

> I think it is just easier to check.
>
> Also what if he has no record that matches PN - then I think his
> programming needs to allow for that possibility and add a record.

Well, that depends on his particular needs.  He does check if the
lookup fails, and gives a message to the user.  It may be that his
needs are such that this is sufficient.

-- 
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com