Switching to update mode from @ENTSEL

[John Esak]

Yup.


> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.com]On
> Behalf Of Barry Wiseman
> Sent: Monday, July 09, 2007 12:31 PM
> To: Filepro-List at Lists. Celestial. Com
> Subject: Re: Switching to update mode from @ENTSEL
> 
> 
> (top-posted for John)
> 
> Thanks, John!  I suspected I was simply experiencing a little 
> brain freeze on this.
> 
> So you're saying, instead of
> 
> 	::1=x:
> do
> 	::lookup myrec = myfile  r=@rn  -ep:
> 	::myrec(1)=x:
> 	::write myrec:
> 
> Should do the trick.
> 
> John Esak wrote:
> > Barry,
> > I do just about everything from @entsel... still there are no 
> good ways to
> > prevent broken header-detail ties if things go awry.  However, 
> instead of
> > the posting to a temporary array, have you thought of doing a 
> lookup to the
> > record your standing on?  It may be locked, but *you* own the 
> lock, so it
> > opens up some possibilities.
> > 
> > John
> > 
> > 
> >> -----Original Message-----
> >> From: filepro-list-bounces+john=valar.com at lists.celestial.com
> >> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.com]On
> >> Behalf Of Barry Wiseman
> >> Sent: Monday, July 09, 2007 12:05 PM
> >> To: filePro list
> >> Subject: Switching to update mode from @ENTSEL
> >>
> >>
> >> I'm trying to rewrite some old programs that do all their work
> >> standing on a locked
> >> record (everything hangs off initial @KEY triggers).  I want to
> >> instead have as much
> >> as possible happen within @ENTSEL processing so that the record
> >> is not locked.
> >>
> >> However, the tree of user interaction runs deep -- various
> >> master/detail browses and
> >> their respective options, some of which require updating the
> >> master record and some
> >> don't.
> >>
> >> Is there some graceful method (that hasn't occurred to me) of
> >> dropping into update
> >> mode at any arbitrary point deep within @ENTSEL processing?  I 
> know I can
> >>
> >> 	::pushkey "U"; end:
> >>   	@UPDATE::' do whatever:
> >>
> >> but then I need flags and a jump table to know why I came there
> >> and it all gets
> >> pretty messy.
> >>
> >> My other thought was to create an array of numfield(-) elements,
> >> and write all
> >> updates there instead of to the current record.  On exit, a
> >> single @UPDATE routine
> >> can loop thru the array, copying whatever's "dirty" into the
> >> appropriate fields.  But
> >> this type of deferred posting seems rife with possibility for
> >> disaster that would
> >> leave transactions corrupted and records out of balance.
> >>
> >> Any suggestions welcome.
> >>
> >>
> >> -----------------------------------------------------------------
> >>   Barry Wiseman                              barry at gensoftdes.com
> >>   Genesis Software Designs, Inc.            Voice: (212) 889-9191
> >>   55 West 45 Street, New York, NY 10036       Fax: (212) 889-1589
> >> -----------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Filepro-list mailing list
> >> Filepro-list at lists.celestial.com
> >> http://mailman.celestial.com/mailman/listinfo/filepro-list
> > 
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > 
> > 
> > 
> 
> -- 
> -----------------------------------------------------------------
>   Barry Wiseman                              barry at gensoftdes.com
>   Genesis Software Designs, Inc.            Voice: (212) 889-9191
>   55 West 45 Street, New York, NY 10036       Fax: (212) 889-1589
> -----------------------------------------------------------------
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list