FW: Browse lookup - odd behavior

[Kenneth Brody]

(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.)

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