Changing a field in the index you're in

[Richard Kreiss]

> -----Original Message-----
> From: Filepro-list [mailto:filepro-list-
> bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Jay Ashworth
> Sent: Monday, March 09, 2015 1:47 PM
> To: FilePro Mailing List
> Subject: Changing a field in the index you're in
> 
> 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?

One thing you mentioned above, FP does cache the record numbers presented in a browse.  I ran into this as a problem some years ago when a billing clerk for one of my clients complained that she would delete a detail line and then a detail line from a new order would appear in her browse.  After reviewing the problem, the deleted record was being grabbed by an order clerk and then displayed on the billing clerks browse.  This problem was systemic to this client and the speed with which new orders were being entered.  The solution was to add the order number to the drop routine so that if the order # didn't match, the record was dropped.  The primary key for the browse was on the order #.

As for your problem, selection of the record should be with @bk= and not @sk= (unless that was a typo).

The other solution, off the top of my head, set the initial lookup value to lv(if not already used) Once the record is selected, do a GOSUB to a lookup using the current key value and index, Do a getnext, which should be the index record in the browse and set  NextRec=foobar() then a return to run your update routine.  Once the current record is updated, loop back and set the lookup value lv=NextRec. 


Richard Kreiss
GCC Consulting

Office: 410-653-2813