Switching to update mode from @ENTSEL

[Barry Wiseman]

(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
-----------------------------------------------------------------