Auto-Save Object Changes: How To Turn Off?

[PeteCresswell]

Somewhere along the line, I must have fat-fingered some option or
another because whenever I close an object that I've made a change to
it no longer prompts me whether to save or not.

Extremely insidious when it comes to accidental changes.

I looked through Tools | Options, but couldn't find anything.

Doesn't mean it's not there.... just that I don't see it.

Can anybody elucidate?

 

[Dirk Goldgar]

Somewhere along the line, I must have fat-fingered some option or
another because whenever I close an object that I've made a change to
it no longer prompts me whether to save or not.

Extremely insidious when it comes to accidental changes.

I looked through Tools | Options, but couldn't find anything.

Doesn't mean it's not there.... just that I don't see it.

Can anybody elucidate?

That usually happens when you've executed the statement

DoCmd.SetWarnings False

(or the equivalent macro action). Could that be your problem? Sometimes
people write code intending to turn the warnings off temporarily, to use
RunSQL and suppress the warning message, but either forget to turn warnings
on again, or an error occurs that bypasses the SetWarnings True statement.

There are also the "Confirm" check boxes on the Edit/Find page of the
Options dialog, but I'm not sure if any of those options governs this
particular warning.

 

[PeteCresswell]

That usually happens when you've executed the statement

    DoCmd.SetWarnings False

Bingo!

Thanks.

Sounds to me like another little bit of boilerplate to add to my
AutoExec routines - since, in debugging, one can interrupt a routine
and provoke that situation without having an unbalanced .SetWarnings
False/True situation in the code.

And it seems to persist even after the app has been closed and then re-
opened. Does that sound right?

 

[Dirk Goldgar]

Bingo!

Thanks.

Sounds to me like another little bit of boilerplate to add to my AutoExec
routines - since, in debugging, one can interrupt a routine and provoke
that situation without having an unbalanced .SetWarnings False/True
situation in the code.

And it seems to persist even after the app has been closed and then
re-opened. Does that sound right?

No, I don't believe that is right (and a quick check indicates that it is
wrong). If you execute "DoCmd.SetWarning False", that setting should last
only for the current session.

Therefore, there is no point in setting warnings on in your startup code --
they should already be on. If it seems to you that warnings are turned off
in your application at startup, I would look very closely at that startup
code to see if it turns them off and doesn't turn them back on again.

Incidentally, this is why I much prefer using CurrentDb.Execute over
DoCmd.RunSQL to execute SQL statements -- I don't have to turn warnings off,
so I'm not concerned about turning them on again. On those rare occasions
that I do turn off warnings, I make darned sure that there's no way the code
can exit the procedure without turning them on again.