FW: Browse lookup - odd behavior

[Kenneth Brody]

"Jay R. Ashworth" wrote:
[...]
> > Or are you suggesting actually re-running the lookup in its entirety?
> 
> Doing anything else seems semantically inadequate, as this problem
> demonstrates.

After some investigation last night, it appears that I misrembered how
the pkeep part of the browse lookup works.

Upon re-executing the pkeep lookup, it is only the initial record whose
position is cached.  From there, the rest of the browse window is repopulated
by scanning the file.

While within the browse, the record numbers are cached so that scrolling
within the window does not re-scan the file.  Also, when scrolling off the
end of the window, everything is shifted within the cache, and only the
newly-vacated area is populated by continuing the scan of the flie.

Since my misremembering of the caching fit the symptoms being reported, I
thought that I remembered correctly.

Which brings us back to the OP's symptoms.

We would need more specifics of what the index is built on, which record
is being deleted, what is in the newly-created record that's replaced it,
specifically the field(s) used to build that index, what records appear in
the window upon re-executing the browse lookup, and perhaps some more
information that I'm not thinking of at this moment.

-- 
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody        | www.hvcomputer.com |                             |
| kenbrody at spamcop.net | www.fptech.com     | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+