LOL

On Fri, 14 Oct 2016 07:35:22 -0700, Kirk Brooks wrote:
> Chip,
> That's one of the places where management comes into play with programming.
> My experiences have been there's no joy in attempting to program in
> management's assumptions of user behavior. Happens to me frequently:
> 
> boss: "set it up so this and that are required for saving this sort of
> record. No exceptions!"
> 
> me: "OK."
> 
>   -- the day these changes go live --
> 
> boss: "Why can't I save this record?"
> 
> me: "Because this and that isn't fully entered."
> 
> boss: "But we need to override that sometimes."
> 
> me: "Ok, but you said 'no exceptions.'"
> 
> boss: "this isn't an exception it's an override."
> 
> me: "I didn't think of that."
> 
> ‚ÄčApologies to Scott Adams.
> ‚Äč
> 
> I don't want to have to care about what management thinks it's doing. So I
> tend to let such conditions be controlled by a preference management can
> set and write the code to work regardless of which is chosen.
> 
> In the case you describe management can rail about completing data entry
> quickly all they want and that won't prevent someone from starting a
> transaction and getting distracted. In a case where those data are really
> critical I'd not let any user lock the record but collect proposed changes
> in variables, submit the variables for saving and do the validation and
> error checking. If it's all good then load the record and write the
> changes.
> 
> On Fri, Oct 14, 2016 at 7:11 AM, Chip Scheide <4d_o...@pghrepository.org>
> wrote:
> 
>> yes.
>> But then :
>> - if the 1 user changed a value, everyone probably needs to know that
>> the record is being modified and whatever value(s) are displayed may
>> not be correct.
>> - if the 'touch' (in code) is only a lookup - Read Only is your friend
>> :)
>> - users learn to finish, after being <redacted> yelled at </redacted>
>> told a few times to complete what they were doing  :)
>> 
>> On Fri, 14 Oct 2016 04:20:58 -0700, Kirk Brooks wrote:
>>> The problem with starting transactions
>>> from an input form in such a way that they are finished by user action
>>> (enter or cancel) is everything you 'touch' within the transaction gets
>>> locked until the user is done.
>> **********************************************************************
>> 4D Internet Users Group (4D iNUG)
>> FAQ:  http://lists.4d.com/faqnug.html
>> Archive:  http://lists.4d.com/archives.html
>> Options: http://lists.4d.com/mailman/options/4d_tech
>> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
>> **********************************************************************
>> 
> 
> 
> 
> -- 
> Kirk Brooks
> San Francisco, CA
> =======================
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **********************************************************************
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************

Reply via email to