Changing a field in the index you're in

[Jay Ashworth]

That sounds too simple.  

Probably cause the data is being added in realtime.  Hmm.  Maybe not.

On March 9, 2015 4:17:13 PM EDT, Jim Asman <jlasman at telus.net> wrote:
>
>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

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20150309/f140cf85/attachment.html>