Changing a field in the index you're in

[Jim Asman]

How about building a demand index and running the operation from it?

--------------- Original Message ---------------
At 01:46P Mon Mar 09 2015, Jay Ashworth wrote:

> 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
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list


Jim 
--
jlasman at telus.net                      Spectra Colour Services Ltd.
Phone: (604)584-0977                   Surrey, BC  CANADA            
 Cell: (604)619-0977                   www.spectracolorservices.com