FW: Browse lookup - odd behavior

[GCC Consulting]

This is a response to my own post.

I Spoke with Ray Hoover today - see below

Ray,

Per my call.

Situation:

Fp 5.0.11 native

Order header & detail files.

When in the order header and listing the order details associated with the order
through a browse lookup based on the order number, when a detail line is deleted
and the browse is then re-executed, periodically an order detail from another
order will appear in the browse window.  

>From what I have found out, the errant detail line is from a new order which is
being entered.

Yes, the problem can be solved by using a drop any details where the
order_numbers don't match. 

Any idea why this is happening?

This is what I was advised may be causing this problem.  The answer came from
Ken and I hope I am explaining it correctly.

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.  

When the browse is re-executed, the  newly entered line for another order
appears either as the first or last item in the browse window as the record # is
still a valid record even though it is not for my current order.

I added a drop routine to check that all records are for the current order.

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.


Richard Kreiss
GCC Consulting