Quick response needed - Can't seem to delete a record!

[Haleigh]

My form has a cmdCancel button which, when clicked, should
cancel creation of a new record and exit the form. For
some reason, however, none of the commands I've tried will
delete! Here's what I've tried:

------------
These commands were produced by the button Wizard:

DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70
DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70

Access Help doesn't really explain what the codes mean, so
I'm not really sure what it's trying to do. Commenting out
either one of the lines doesn't do anything, but together
they produce the error "The Search Key was not found in
any record."
-------------
I found the following code in this community:

DoCmd.SetWarnings False
DoCmd.RunCommand acCmdDeleteRecord
DoCmd.SetWarnings True

This also produces the error "The Search Key was not found
in any record."
--------------

I know that, as soon as you enter something into a field,
Access creates the record in the table, whether you
actually Save the record. But, for the heck of it, I've
tried issuing "DoCmd.DoMenuItem acFormBar, acRecordsMenu,
acSaveRecord, , acMenuVer70". The same error message
occurs.

BTW, the form is set to allow edits, deletions, additions
and data entry.

Could someone advise what is going on ASAP?

Thank you very much,
Haleigh

 

[Allen Browne]

To cancel the creation of a new record (or the changes to an existing
record) before it is saved, just undo the form:

Private Sub cmdCancel_Click()
If Me.Dirty Then
Me.Undo
End If
DoCmd.Close acForm, Me.Name
End Sub

 

[Ken Snell [MVP]]

To cancel a record that hasn't been saved yet (which I believe is what
you're describing), use this one line of code:

Me.Undo

 

[Haleigh]

Thank you, Allen and Ken, for responding so quickly. I'll
give your directions a go.

In the meantime, could you please tell me, what is the
purpose of having a Save command if everything you type
into a bound form is written directly to the table anyway?

Haleigh

 

[Allen Browne]

I'm not sure what you mean by "a Save command", but explicitly saving a
record can avoid a raft of issues.

There are many reasons why a record cannot be saved, e.g. if a required
field is missing, or a validation rule is not met, or it would create a
duplicate of something marked "Indexed (No duplicates)". There are also
concurrency issues where another user or process is attempting to use the
same data at the same time. And then there are bugs where Access just
silently loses what you typed without informing you that the record did not
save:
http://members.iinet.net.au/~allenbrowne/bug-01.html

This can get very messy, particularly where you have interacting events,
users, and processes. For example, if you are editing something in the main
form, and then click in the subform, you may not be aware of the chain of
events that you just fired:
1. text box's BeforeUpdate
2. text box's AfterUpdate
3. text box's Exit
4. text box's LostFocus
5. form's BeforeUpdate
6. form's AfterUpdate
7. form's AfterInsert (if it was a new record)
8. the subform control's Enter event
9. Enter event of the control in the subform
10. GotFocus event of the control in the subform
11. Click event of the control in the subform
and probaby heaps of other events such as the MouseMove of every control you
passed the mouse over, which actually intersperse with the other events.

Now add the chance that you have more than one form open and looking into
the same data (e.g. a search form as well as the editing form), and which
ones have a record that needs to be saved? At the same time?

And maybe there are other users who are also firing their own chains of
events and editing the same data?

Hmm... it starts to make sense to think about:
- explicitly saving the record in the form before opening another into the
same data;
- explicitly saving the record before closing the form (the bug above);
- explicitly saving the record before trying to do something with it;
- explicitly saving the record before trying to move to another record,
apply a filter, change the sort order, change the recordsource, print the
record that has not been saved yet, ...

In essence, forcing the save helps reduce concurrency problems and avoid a
raft of errors and bugs that can be triggered by allowing the events to
interact in unpredictable ways.