Mecki:

1. Yes, mandatory fields are handled with a grand save here.  We have a several 
LIVE examples of grand saves here.
2. Every time a user changes any field of data, it is saved; there is no way to 
cheat.
3. Our sever might be down for a half-hour per year.  Thus, a strong argument 
cannot be made (either way) for this functionality.
4. Half of the contact data in a CRM system is better than none.  Just because 
the cell phone field might be blank does not mean that any of the other data is 
"corrupted".
5. In an airline reservation system, end-users' screens need to show fresh 
real-time data.  Passengers and airport check-in clerks cannot wait ten minutes 
for grand saves.  Adobe's new LiveCycle Data Services allows for discrete field 
updating over the web.
6. While I agree that multiple users manipulating the same record 
simultaneously is highly problematic, it is important to frame the issue 
correctly.  I like to think of it as real-time interactive record updating.  
Every second, a fresh read shows the latest.

--Bill  

-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann
Sent: Wednesday, September 01, 2010 3:34 PM
To: U2 Users List
Subject: Re: [U2] [UV] Shared Record Locks

 Bill,

How do you handle mandatory fields with your technique?
What guarantees that a user doesn't just kill a session before all input is 
done to cheat the system?
And that is in my experience much more likely than a server crash.
There probably is a very good reason why nearly every programmer prefers the 
"grand save" when input is complete.
I rather have no record at all than corrupted data due to missing mandatory 
fields.
And the idea of multiple users manipulating the same record simultaneously 
makes me feel very uncomfortable.

Mecki

On 01/09/2010 18:58, Bill Brutzman wrote:
> Mecki:
>
> I guess that a lot of programmers (perhaps most of them) write programs where 
> when editing say a new Customer... address, phone, etc... open a screen and 
> let the end user update the fields and then finish with a grand save... all 
> at once... on all the records (fields) for that customer.
>
> Of course, if the server goes down while the user is taking minutes to fill 
> in the screen, the user loses everything for that customer and then has to 
> start over with that customer.
>
> I prefer to save the entire record each time a field is changed.  Granted, 
> this is a lot more writes to disk but it handles the given problem.  If two 
> users are looking at the same data, their screens are updated following each 
> discrete transaction.
>
> I do like the given readu technique; I will consider using it.  Thanks for 
> writing.
>
> --Bill
>
> -----Original Message-----
> From: u2-users-boun...@listserver.u2ug.org 
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki 
> Foerthmann
> Sent: Wednesday, September 01, 2010 1:00 PM
> To: U2 Users List
> Subject: Re: [U2] [UV] Shared Record Locks
>
>  Bill,
>
> I thought doing something similar myself when I was a Junior programmer 
> because some people tend to lock records and go for lunch etc..
> But what happens if you read the record into the variable R.This do some 
> processing, then the phone rings and you talk for 10 minutes, while somebody 
> else uses the same process, changes the record and writes it back using your 
> subroutine and then you come along and over-write that record once you get 
> off the phone?
> Not a good idea!
> If you can update a record I recommend always using READU with the LOCKED 
> clause.
>
> What about a loop like this?
>
> LOOP
>    READ.OK = 1
>    READU REC FROM FILE,ID LOCKED READ.OK = 0 ELSE REC = ''
> UNTIL READ.OK DO
>    * Do some processing if record is locked - like
>    CRT 'Record locked - Try again <Y/N>? ':
>    INPUT ANSW
>    IF ANSW = 'N' THEN ABORT
> REPEAT
>
> You may even want to write a subroutine to do that if you prefer.
> You can do some fancy stuff like displaying who's locking the record so the 
> user can ring that person up and tell them to carry on and release the lock.
>
> On 01/09/2010 15:30, Bill Brutzman wrote:
>> I wrote the following little sub...  I guess that it works.
>>
>> --Bill
>>
>>
>>   SUBROUTINE SUB.LOCK.AND.WRITE.R2 ( R.This, This.File, Record.ID )
>>
>>   prompt ''
>>
>>   open This.File to F.This.File  else  gosub  Error.Opening.File
>>
>>   gosub Lock.And.Write
>>
>>   go    The.End
>>
>> *--------------------------------------------------------------------
>> -
>> --------
>> *--------------------------------------------------------------------
>> -
>> --------
>> Lock.And.Write:
>>
>>   Lock.Test = recordlocked (F.This.File, Record.ID)
>>
>>   begin case
>>         case Lock.Test =  0   ;                recordlocku F.This.File, 
>> Record.ID   
>>                                write R.This          on F.This.File, 
>> Record.ID 
>>                                                 release F.This.File, 
>> Record.ID
>>
>>         case 1                    ;  gosub Error.Record.Locking 
>>   end   case
>>
>> return
>>
>> *--------------------------------------------------------------------
>> -
>> ---------
>> Error.Opening.File:
>>
>>   crt @(-1)
>>   crt @(-5)
>>
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt '      Big Problem...                                ' : @(-6)
>>   crt
>>   crt ' _________________________                          '
>>   crt ' \                        \      ' : This.File
>>   crt '  \   Error Opening File   \                        '
>>   crt '   \________________________\    Contact HK.IT      '
>>   crt '                                               [X]  ' 
>>   crt '                                                '   :
>>
>>   input Ans, 1
>>         Ans  = upcase(Ans)
>>
>>   begin case
>>         case Ans = 'X'  ;  null
>>      case 1          ;  go Error.Opening.File   
>>   end   case
>>   
>> return to The.End
>>
>> *--------------------------------------------------------------------
>> -
>> ---------
>> Error.Record.Locking:
>>
>>   crt @(-1)
>>   crt @(-5)
>>
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt
>>   crt '      Big Problem...                                ' : @(-6)
>>   crt
>>   crt ' _________________________                          '
>>   crt ' \                        \      ' : This.File
>>   crt '  \   Error, Record Lock   \                        '
>>   crt '   \________________________\    Contact HK.IT      '
>>   crt 
>>   crt '                                 Open New Gull Session, Try UNLOCK.ME 
>>     '                       
>>   crt '                                                                     
>> [X]  ' 
>>   crt '                                                                      
>> '   :
>>
>>   input Ans, 1
>>         Ans  = upcase(Ans)
>>
>>   begin case
>>         case Ans = 'X'  ;  null
>>      case 1          ;  go Error.Record.Locking
>>   end   case
>>   
>> return to The.End
>>
>> *--------------------------------------------------------------------
>> -
>> ---------
>> The.End:
>>
>>   RETURN
>>   END
>>
>>
>> -----Original Message-----
>> From: u2-users-boun...@listserver.u2ug.org
>> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry 
>> Taylor
>> Sent: Tuesday, August 31, 2010 3:35 PM
>> To: U2 Users List
>> Subject: [U2] [UV] Shared Record Locks
>>
>> Has anyone a real-world application where UniVerse shared record locks are 
>> used?  I'm struggling with when they would be preferable to using an update 
>> record lock.  Anyone willing to "share" their experiences?
>>
>> Thanks.
>>
>> Perry Taylor
>> ZirMed
>> 626 West Main St , 6th Floor
>> Louisville, KY 40202
>> www.zirmed.com <http://www.zirmed.com/>
>>
>>
>>
>>
>> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
>> for the sole use of the intended recipient(s) and may contain confidential 
>> and privileged information.  Any unauthorized review, use, disclosure or 
>> distribution is prohibited. ZirMed, Inc. has strict policies regarding the 
>> content of e-mail communications, specifically Protected Health Information, 
>> any communications containing such material will be returned to the 
>> originating party with such advisement noted. If you are not the intended 
>> recipient, please contact the sender by reply e-mail and destroy all copies 
>> of the original message.
>> _______________________________________________
>> U2-Users mailing list
>> U2-Users@listserver.u2ug.org
>> http://listserver.u2ug.org/mailman/listinfo/u2-users
>> _______________________________________________
>> U2-Users mailing list
>> U2-Users@listserver.u2ug.org
>> http://listserver.u2ug.org/mailman/listinfo/u2-users
>>
> _______________________________________________
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
> _______________________________________________
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to