complimentary lookup criterion question

[Bruce Easton]

Well you wouldn't want to make the length of the portion of the lookup 
key based on any content value, but you really want it to be based on 
the length(s) defined for the index for the part(s) that's supposed to 
match exactly. Normally, it would be for the full length of each field, 
but just note that any part of an index *could* be built on part of a field.

For instance, for some odd reason, a developer may have defined the 
first part of an index on a name field of length 30 to actually be built 
only on the first 20 chars of that field.  In a scenario like this, 
that's what should match the corresponding portion of the lookup key 
(before you get to the date and time).

Bruce


On 7/25/13 11:50 AM, Fairlight wrote:
> So if you're doing this with a field of length 20, but the value is only
> 17, concatenate using & with fields that are cast to the actual field
> lengths, not the content lengths?
>
> m->
>
> On Thu, Jul 25, 2013 at 11:34:40AM -0400, Bruce Easton thus spoke:
>> I should have also stated that the lengths of the field(s) that are used
>> in the lookup (where I call them "myexactkeys") should be exactly the
>> same as the length(s) that are used for the portions of the
>> corresponding index used (not the length of the fields the portions are
>> built against which may very well be the same, but the specified index
>> length(s)  for the field(s) in the lookup file where those portions must
>> match the first part(s) of the lookup key exactly.
>>
>> Bruce
>>
>> On 7/25/13 11:23 AM, Bruce Easton wrote:
>>> Mark, if you build an index across the fields separately, where the
>>> first field(s) is/are the ones that must match exactly to the key you
>>> supply, and with the last two fields as modified date then time (where
>>> each of those fields have filepro date, time system edits), then you
>>> should be able to find the most recently modified records with a key
>>> similar to this:
>>>
>>> lookup lastm=(myfile)  k=(myexactkeys&"12/31/299923:59:59") i=A  -nl
>>>
>>> (assuming that your date edit to match this example would be mdyy/ and
>>> a system time edit).
>>>
>>> Since it's not an exact match lookup, you would want to check
>>> immediately after the lookup, both
>>>
>>> If: not lastm
>>> Then: 'do something but don't fall to next test where it would be
>>> illegal to test lastm(##)
>>>
>>> and
>>>
>>> If: lastm(##) ne myexactkeys     'found next less, but no longer
>>> matches keys that must match exactly
>>> Then: 'do something
>>>
>>> Similar code could be used for 8-digit dates where you would probably
>>> want to set the key value for the year portion of the lookup to be as
>>> high as possible (instead of my arbitrarily-high "2999") within the
>>> PFCMARK range (by getting the value for PFCMARK and I think you have
>>> to subtract one year from that and use that as the two-digit highest
>>> year value).
>>>
>>>
>>>
>>> Bruce
>>>
>>>
>>>
>>> On 7/25/13 10:25 AM, Fairlight wrote:
>>>> I need to look up a record from within input processing by two
>>>> criterion:
>>>>
>>>> 1) The absolute value of a field matching (key field lookup)
>>>> 2) I need the most recently modified record which matches criterion
>>>> #1, as
>>>> well as has a particular value in a secondary field.
>>>>
>>>> I have date and time fields, and there's even an index built across
>>>> both,
>>>> in descending order for both.  Unfortunately, I don't think that does
>>>> me a
>>>> lick of good, since a key field lookup will be using the index for that
>>>> field, not the date/time index.
>>>>
>>>> I thought about the possibility of a four-field index across all four
>>>> fields, but in thinking about it, I have come to the conclusion that
>>>> there's no way it's remotely useful, as I won't have a specific date to
>>>> use for the second 2/4 of the key field, and I don't think the joint
>>>> index
>>>> works that way.
>>>>
>>>> Is there an efficient way to handle this situation?  If so, what is it?
>>>>
>>>> I'm envisioning lots of getnexts and tracking the last @rn that had the
>>>> highest value, then when the lookup has exhausted all records which
>>>> match
>>>> the two specific values, flip back to the record at the most appropriate
>>>> @rn value.  Is that the only real way to skin this cat?
>>>>
>>>> mark->
>>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> Subscribe/Unsubscribe/Subscription Changes
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>