Getting user data saved - What's good practice?

  • Thread starter Thread starter Laurel
  • Start date Start date
L

Laurel

Is there a way to force the most recently entered row to be saved without
requiring that the cursor move off of it into the next 'new' row? In
another language there is an "AcceptText" event that can be triggered to put
the data into the save buffer.

Practical issue is that I have a form where the user can add rows of student
scores for a class/date combination. They also have the option of clicking
a button that will create rows for all of the students in the class at once.
My problem was that if the user clicked the button to trigger the mass
update while the cursor was still sitting on the most recently entered row,
then the routine didn't know about it, and created a row for the same keys.
Then when the user-entered row was subject to 'save' there was a duplicate
key error. I solved the problem by disabling the mass update button while
the user was in row-entering mode. But I was sorry to have to do that.
 
Is there a way to force the most recently entered row to be saved without
requiring that the cursor move off of it into the next 'new' row?

Yes; in an appropriate event use either

DoCmd.RunCommand acCmdSaveRecord

or

If Me.Dirty = True Then Me.Dirty = False
 
Thanks. Time prevents me from undoing my unsatisfactory fix and trying this
out right away, so I'll ask now if this works where DoCmd.Save does not
work? In my scenario the user data is not yet known by Access, so the
DoCmd.Save doesn't help.
 
Thanks. Time prevents me from undoing my unsatisfactory fix and trying this
out right away, so I'll ask now if this works where DoCmd.Save does not
work? In my scenario the user data is not yet known by Access, so the
DoCmd.Save doesn't help.

DoCmd.Save doesn't save data; it saves *design changes to the Form*.
Ordinarily (one would hope!) the user isn't changing the structure of
the form itself, so DoCmd.Save is very rarely going to be useful.
 
Back
Top