issues with called table causing lookup behaviour change...need help

Bruce Easton bruce at stn.com
Fri Aug 9 12:03:51 PDT 2013


On 8/9/13 1:22 PM, Fairlight wrote:
> On Fri, Aug 09, 2013 at 10:17:43AM -0400, Kenneth Brody thus spoke:
>> On 8/8/2013 6:00 PM, Fairlight wrote:
>>> I have a table sitting (with -sr 1) on a record, doing a lookup to another
>>> table.  I'm looping through all records in that table with a -ng lookup on
>>> an index.
>> [...]
>>> Here's the kicker.  During that -db trace, I found that the
>>> "not lookupname" is evaluating true after that one run past the table in
>>> question.  If I yank the call, it apparently must not be, as I get a second
>>> msgbox.  (There are currently only two records that would trigger the
>>> call/msgbox combination.)
>>>
>>> What about a call would cause the lookup to go screwy?  Is it because the
>>> records I'm looking through are the same table that the called table is
>>> altering?  It's not even altering the field upon which the index for the
>>> lookup in question is based.
>> Does the called table do a lookup to that same file, and CLOSE the lookup?
> The called table does -two- lookups to the same file.  Both are closed.
> But they're not the same lookup alias as the one in the parent (calling)
> table.
>
> Is this still a problem?  If so, I could use a fix.
>
> mark->
Yes, that's still a problem, Mark.   A close in the called table will 
close for all open lookups on the same file whether they are in the 
called table or in the main table and regardless of alias.  This is 
consistent with how lookups are handled for the same file just in the 
main table.

Bruce



More information about the Filepro-list mailing list