@WEF. @WLF in @ENTSEL

[Barry Wiseman]

Brian K. White wrote:
> ----- Original Message ----- 
> From: "Barry Wiseman" <barry at gensoftdes.com>
> To: <filepro-list at lists.celestial.com>
> Sent: Monday, September 24, 2007 12:56 PM
> Subject: Re: @WEF. @WLF in @ENTSEL
> 
> 
>> Boaz Bezborodko wrote:
>>
>>> If you are so interested in keeping the record out of update mode then
>>> why not work from a separate, duplicate file (or even just a separate
>>> qualifier)?  When selecting the record to work with COPYIN the data to
>>> the new working record.  Once you're ready to update any particular
>>> piece of data you update the original record.  The original file is only
>>> open very briefly for the updates.  When you're done you simply delete
>>> the separate working record.
>> Actually, that doesn't solve anything; by your scheme, two users still 
>> cannot be in
>> the same record.  But thanks for the suggestion. :-)
> 
> Actually I think that would help quite a lot in most cases.
> The implication was that users always stand on a new free record in the 
> standing file, and they don't lock the original files record to copy it into 
> the current record they are standing on in the standing file.
> 
> So far, 200 users can do that at the exact same instant and all work on 
> their own copies concurrently.
> 
> When you hit a spot where you need to modify the source record on disk, then 
> you lock/write/release in a flash.
> Users can't all do that simultaneously, but at the speed of typical 
> computers, I bet several hundred or even thousands could do it within the 
> same second, and since fp will wait for a record to become unlocked and then 
> proceed normally, the users never actually perceive that they hit a locked 
> record for a split second, if they even ever do hit a locked record.
> 
> Granted lot's of times you can't operate that way depending on what kind of 
> editing each user might be doing.
> You might need to always check if the source record had been updated since 
> the time your current process copied it and the time it wants to write a 
> change, which might get impractical depending on the particular program of 
> the moment.

I misread Boaz's suggestion as, "Maintain a mirror of the key and let users stand on 
that mirror key."  I use the dummy file technique he and Brian are referring to in 
some cases, and it is every bit as powerful and helpful as Brian says.

Here it's unworkable because the users are accustomed to using filepro selection, so 
they need to be standing on the actual key (or on a mirror thereof, which as I said 
wouldn't help anything).

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