After trying many different combinations, we do exactly what you are doing. The
beauty of Pessimistic Locking is that if the .Edit takes, you know you *own* this
record for the time between moving data to the record fields and the eventual .Update
This is also true of .AddNew  If no error occurs, you can be assured the new record
will be added.

The only times I have seen programs where a user can bring up a record, walk away and
lock all other users out are cases where PC bred programmers who grew up owning the
entire machine were thrust into multi user apps and either not given directions or
not thinking about concurrency issues.

Can someone please answer a question regarding pessimistic locking with Jet
3.5 ?

I am using unbound controls and my own procedures to move data between form
controls and my recordset - no data controls.

If I use pessimistic locking but don't invoke the .edit method on my
recordset until the save button is clicked on my form, the record should
only be locked for the time my procedure takes to copy
the data from the controls on my form and save the record.

If my recordsave procedure encounters a lock by another user, I have a retry
procedure to back off and try again.

Will this work ? or am I missunderstanding the locking techniques.

I'm trying to avoid the situation where ( if I invoke the .edit method as
soon as a user starts changing information on a form) and the user then
walks away from the screen leaving the record locked.

Thanks,

You could add a Timer control that would go off after a predetermined amount
of time and (assuming recset is scoped to the Timer sub) :

Private Sub Timer1_Timer()
    if g_recset.EditMode <> dbEditNone then
        g_recset.cancelupdate
        msgbox "Your coffee breaks are getting a bit long aren't they?"
    end if
end sub

Personally I try to ensure that Edit or AddNew and Update get called within
the same procedure. I usually load recordset values into an object's member
variables or things like textbox text properties. Then when the recordset is
to be updated I call edit, update field values and then call update.

don

I think it's important to realize the other side of the coin as well...

While pessimistic locking does truly "take over" the record from possible
edit by all users, there are some occasions where this is desirable.  For
example, you may have an app with a form that has several tabs on a tab
control.  Each tab may have 5 or 10 fields, and some require lengthy
"memo-text" entry or thought-provoking choices.   The typical user might
spend 5 or 10 minutes entering the data for this type of record.

At my last job, we actually *desired* to truly lock the record while editing
because we didn't want one user to spend 5 or 10 minutes setting up an
employee record (on a complex form as described above), only to hit OK to
save his record and find out someone else had just updated (or created in
the case of a new record) the record in the meantime, and his screenful of
data was now stale and he had to lose his changes so he could re-acquire the
latest copy of the record.

Now, all this must be weighed against the liklihood of conflict over the
same record (depending on the number of users and the nature of the
application), as well as the complexity of the forms, and the user's ability
to deal with "losing" their changes if this should occur.   Doing all of
this analysis is truly "thinking about concurrency issues", regardless of
which method is finally deemed most appropriate for the particular
application and user base.

I just think it should be pointed out that there are always two sides to
every coin, and choosing to lock a record pessimistically (during editing)
should not be globally categorized as "poor programming".  Every
application, its usage, and its customer base is different.  It's important
to view all those factors when deciding on an important architectural
paradigm such as how you want the application to respond in a multi-user
environment.

Vinnie Murdico
Software with Brains, Inc.
http://www.softwarewithbrains.com