lookup wackiness

[Nancy Palmquist]

Fairlight wrote:
> Explain this, if you can...
> 
> * Index field based on field with (8,RJFILL0) cast.
> 
> * Key field that was uncast, but had 8 characters.
> 
> Lookup fails in -most- cases (77889908, 00000abc, 00000001, etc.) that
> still match the actual data in the index field of the lookup.
> 
> Lookup SUCCEEDS on 00000111 for value.
> 
> Casting the key field to (8,RJFILL0) fixes the problem of spurious
> failures.
> 
> Whacked.  It should either work or not, but not "sometimes".
> 
> Moral:  Fail to cast your lookup key fields at your own peril.
> (Apparently.  First time it's ever bitten me.)
> 
> mark->

Mark,

The edit on a key and the index data should match for sanity sake.

You will find that some edits change the nature of the data.  For example, and 
uncast key field that contains 00000111 would be treated as a number, but a 
value of 00000abc would cause it to be treated as a literal.

The comparison to the index may be affected by this difference in nature.  By 
assigning an edit to the field you eliminate these kinds of misinterpretations.

I use doedit("00000111","rjfill0","8") instead of giving the key field an edit, 
many times.  I always hated to use 2 or more variables when one would do, just 
to vary the edit applied.

Nancy

-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com