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

On Fri, Oct 14, 2016 at 7:11 AM, Chip Scheide <>

> 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:
> Archive:
> Options:
> Unsub:
> **********************************************************************

Kirk Brooks
San Francisco, CA
4D Internet Users Group (4D iNUG)

Reply via email to