FW: Browse lookup - odd behavior

[Jay R. Ashworth]

On Wed, Jul 14, 2004 at 11:18:01PM -0400, Kenneth Brody wrote:
> (Mis-quoting corrected.)
> 
> GCC Consulting wrote:
> [...]
> > From what I have found out, the errant detail line is from a new order which is
> > being entered.
> [...]
> > > When using pkeep in a browse, the browse keeps track of the records being
> > > displayed by record number.
> > > 
> > > So, when a detail record is deleted, using a write and sync, and another order
> > > is being entered, it is possible that the new order detail record is the one
> > > just deleted.
> [...]
> > Based on the speed of today's computers it may seem a little far fetched for a
> > record to be deleted and an instant later be grabbed by another person doing
> > order entry and having that new detail display in  browse window for a
> > completely different order.  But this has happened more then  once at this site.
> 
> To summarize:
> 
> Suppose you have a pkeep browse lookup with the following records displayed:
> 
>     1
>     2
>     3
>     4
>     5
> 
> You now delete record 3 and re-execute the lookup.  filePro re-reads records
> 1, 2, and 3, and sees that record 3 is deleted, so it removes it from the
> list of displayed records, reads 4 and 5, and then reads 6 to fill in the
> gap created by removing record 3:
> 
>     1
>     2
>     4
>     5
>     6
> 
> Now, suppose that record 3, after being deleted by you, were to be recreated
> by another process using lookup-free.  (You did say that the erroneous record
> was one that was just created.)  Now, filePro re-reads records 1, 2, and 3,
> and 3 is still a valid record (though the contents have changed since you
> last displayed it), so filePro keeps it just as it did 1 and 2, so it keeps
> on reading 4 and 5, leaving:
> 
>     1
>     2
>     3
>     4
>     5
> 
> However, record 3 no longer fits your original criteria for which records
> are to be displayed.
> 
> Try logging which records you delete, and display the record number in the
> browse lookup.  When a "wrong" record appears, check the log to see if that
> record was the one you just deleted.  (I'm assuming that the user probably
> won't remember the record numbers that were displayed just prior to the
> "wrong" record appearing.)

I came in late, but is the lookup index-based?

Cause if it is, I submit that filePro internally caching the record
numbers is either a poor design decision, or a bug -- as indicated by
the trouble that prompted this thread.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	"You know: I'm a fan of photosynthesis as much as the next guy,
	but if God merely wanted us to smell the flowers, he wouldn't 
	have invented a 3GHz microprocessor and a 3D graphics board."
					-- Luke Girardi