Changing a field in the index you're in

[Jay Ashworth]

Here's a problem I had to solve 20 years ago, and I no longer have that
code on a readable drive, so I have to solve it again.  Suggestions welcome.

I have a user in a file via a browse on index P, which includes the fields

Student ID
Match Percentage Descending

So all the records with no Student ID come first, with the best matches at 
the top, and the ones which the earlier matching process got hits on are 
later, in order by Student ID (since that's obviously a unique key; the
fact that there's a subordinate sort is immaterial).

The user's job is to go into the first record, and work their way through
the matches as the index presents them to them, using an @key process to
pick an existing student from a browse into the student file, or 'N' to 
create a new student ID and automatically set that as the match.

My plan was to have the accepting of a match automatically move the user
along to the next record in the index, until they run out -- there will 
generally be a dozen or two records a day in this file, which are
archived after posting.

Old hands at filepro will already have spotted the bug in this process, but
for those who are on my lawn (:-), it is this:

The index I'm moving along *contains the field I'm changing*, and filePro
does not cache the "next" and "previous" record pointers *by record number*
when it arrives at a record, it figures them out when you try to use them.

So once I change that Student ID, my current position along the index skips
to wherever that puts me, way down; if I add a new one, I go to the bottom.

And therefore, I have to make my user do a metric shitload of manual nav.

This is bad.

When I tripped over this in 96, in a similar Run The Batch situation, while
I don't remember how I fixed it, I *do* remember passing a pissy comment in 
my source identifying exactly what line of the filePro sources causes it --
that client had been a porting site for the AT&T 3b2 port, and had complete
4.1 sources on their machine.  :-)

I'm having trouble figuring out how to fix it again, and I'm hoping someone 
has had to do so more recently.  (Well, I was *actually* hoping that having
to explain it to the teddybear would magically bring me the answer, but not
yet, alas.)

Any ideas, folks?

In a related story: has anyone ever *depended on this behavior*, such that
they would break things if they 'fixed' it?

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274