@WEF. @WLF in @ENTSEL

[Boaz Bezborodko]

>
> Date: Mon, 24 Sep 2007 13:55:46 -0400
> From: Barry Wiseman <barry at gensoftdes.com>
> Subject: Re: @WEF. @WLF in @ENTSEL
> To: filepro-list at lists.celestial.com
> Message-ID: <46F7FA22.1050907 at gensoftdes.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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
> -----------------------------------------------------------------
>
>   
One way you could do this is to create a separate lookup program for 
them  so that their lookup looks similar to what they are used to.  You 
could even emulate the variety of index options available using Listbox 
to jump to different browse lookups.  They wouldn't have to stand on the 
key and their selection can be made to look very similar.

In any case don't you have problems with creating race conditions where 
one user can overwrite changes that were just made by another?