Inconsistent behaviour of Undo

[Rob Parker]

I have the following code in a Close button on a form:

Private Sub cmdClose_Click()
'delete new record with no description
If Me.OpenArgs = "New" And IsNull(txtDescription) Then
Me.Undo
End If
DoCmd.Close acForm, "frmArising"
End Sub

I'm using this since the form is dirtied by code which enters default
values for several fields; what I want to do is delete the record if no
description has been entered. My problem is that sometimes this works,
and sometimes (mostly) it doesn't (ie. the record is saved when both
tests in the If statement are true).

It seems that the record is never saved if I run the code by stepping
through it, but if I just let it run unhindered then the outcome is
inconsistent - sometime the record is saved, sometimes not.

The application (Access 2003) is split, with a local front-end with
links to a back-end .mdb file on a network server. The form's
recordsource is a query based on a linked table.

Any suggestions/comments gratefully received,

Rob

 

[aaron.kempf]

you should do this:

a) use the command button wizard to make an undo button
b) copy the code

DOcmd.undo doesn't undo changes to the record; it's for changes to the
forms / reports.. not the data

-Aaron

 

[Rob Parker]

Thanks for the response, Aaron.

The Help file states: "If the Undo method is applied to a form, all
changes to the current record are lost. If the Undo method is applied
to a control, only the control itself is affected." The Me.Undo IS
preventing the record being saved - presumably by undoing all the
changes made by code, so that reverts to being a clean new record,
which is not saved when the form closes - when I step through the code,
and sometimes when the code runs normally.

Your suggestion of an undo button is not what i need - in fact, I
already have a Cancel button on the form (which, BTW, uses Me.Undo and
(seems to) works fine). I'm attempting to prevent a new record being
generated when a user fails to use the Cancel button, and instead uses
the Close button.

I guess that an alternative approach would be to explicitly save the
record, then delete it. In fact, I've just done some more testing and
find that the thing which forces the save is moving into any field in a
sub-form of the main form. I guess that's why the Undo works sometimes
and not others - it will depend on exactly what the user has done. And
I guess that makes the alternative approach the one which I will now
implement.

Rob

 

[aaron.kempf]

look ****er

when I tell you what to do you need to do it ok?

grab the code and use that method instead of you Docmd.Undo.

you're using the WRONG undo.

-Aaron

 

[Allen Browne]

Rob, it might be worth testing whether the record is already saved at the
time when the button is clicked. There are many, many things that can
trigger the saving of the record, such as tabbing out of the last control in
the active tab order, or pressing Shift+Enter.

To test it:
If Me.Dirty Then
MsgBox "Dirty"
Else
MsgBox "Not dirty."
End If

 

[aaron.kempf]

isn't he just trying the WRONG UNDO?

-Aaron

Rob, it might be worth testing whether the record is already saved at the
time when the button is clicked. There are many, many things that can
trigger the saving of the record, such as tabbing out of the last control in
the active tab order, or pressing Shift+Enter.

To test it:
If Me.Dirty Then
MsgBox "Dirty"
Else
MsgBox "Not dirty."
End If

 

[Rob Parker]

Thanks Allen.

I posted this originally via the Google Groups interface (accessible from my
work environment - the direct MS newsgroups are not). And I received a
reply from (a very arrogant and rude) Aaron, which prompted some further
investigation on my part. I found that, indeed, under some circumstances
(including moving to a control on a subform - even without entering any data
there), the record would be saved. I've therefore changed my code to
explicitly save the record, then delete it. That seems considerably more
bulletproof than using Me.Undo.

I assume that the code snippet you posted to test whether the record has
been saved relies on the Dirty property being reset (to False) when the
record is saved. Is this correct? As I said in my original post, my form
is dirtied when opened by code writing values to certain fields.

As an aside, I don't see the thread which arose in Google Groups here (I'm
using Outlook Express as my newsreader at home), although my original post
to the group via Google Groups is here. I assumed that the follow-up posts
would make it to the real newsgroup, but it seems not. I realise it's
somewhat OT, but do you know anything about that?

Rob

 

[susiedba]

yeah, MIcrosoft CENSORS people who disagree with them.

I think that HITLER did the same thing

-Susie, DBA

 

[Allen Browne]

These groups are managed by Microsoft, so replies that may have been posted
via another news server may not make it to the Microsoft communities if the
poster is an unhelpful flamer.

IME, this helps maintain the tenor of the communities. In reality it is a
very small portion of the community that is socially inept, but if it is not
checked it has a very large effect on everyone. Microsoft certainly doesn't
censor the groups just because someone criticizes them. You'll find lots of
posts where I complain about some bug in Access that hasn't been fixed.
Those posts are not censored; in fact, in some cases Microsoft has added the
issues I raised to their knowledgebase to help users avoid the bugs and
traps. If you are not familiar with the MS knowledgebase, see:
http://support.microsoft.com/search/?adv=1&spid=915

Glad you were able to identify the cases where the record was already saved.
Another alternative, if you always wanted to prevent the record being saved
if there is no description would be to open the table in design view, and
set the field's Required property to Yes.

 

[aaron.kempf]

Microsoft doesn't censor a group just because I criticized them?

eat a dick sandwich bro; I personally got censored BEFORE I EVER
STARTED SWEARING
eat a dick sandwich bro; I personally got censored BEFORE I EVER
STARTED SWEARING
eat a dick sandwich bro; I personally got censored BEFORE I EVER
STARTED SWEARING