How can I detect the current SetWarnings setting?

A

A C

Hi

How can I detect the current SetWarnings setting? As an example I do not
want to restore docmd.SetWarnings true if the calling routine had already
turned it off and would like it to stay off on the routine's return.

Ideas?

Thanks
A
 
D

Douglas J. Steele

I seem to recall a discussion a year or more ago that concluded that it
wasn't possible.
 
A

A C

Douglas J. Steele said:
I seem to recall a discussion a year or more ago that concluded that it
wasn't possible.
Click to expand...


I was hoping the power of human invention had come up with something since
then :)
Note to MS: this would be a nice feature.
 
D

David C. Holley

I would suggest that its not really neccessary to DETEct the
SetWarnings. Just use the DoCmd.SetWarnings command wherever you want to
ensure that Warnings are ON or OFF. I doesn't do any harm to execute the
command twice as in

DoCmd.SetWarnings False
DoCmd.SetWarnigns False
 
A

A C

David C. Holley said:
I would suggest that its not really neccessary to DETEct the
SetWarnings. Just use the DoCmd.SetWarnings command wherever you want to
ensure that Warnings are ON or OFF. I doesn't do any harm to execute the
command twice as in

DoCmd.SetWarnings False
DoCmd.SetWarnigns False
Click to expand...

The issue is more related to "leaving no footprints" when writing a new
routine. Imagine I have a routine which as its standard behaviour turns
warnings off at the beginning and on again at the end. If someone calls
that routine warnings will *always* be set to OFF when it returns. So my
routine has not left the system in the same states as before it was called,
and this may result in unexpected warnings happening in the routine which
called mine.

What would be nice is to take a local copy of the current warnings state at
my routine beginning, and then reinstate that at its end. This way my
routine "leaves no footprints". As it stands we are having to always reset
the warnings to what our local routines want them to be immeditely after we
call any other routine just in case that called routine did some SetWarnings
and hence may have left it in a different state. Its a pain.

Regards
AC
 
A

Albert D.Kallal

I agree that grabbing the "state" of the settings, and retiring them back is
important.

In older systems like the old FoxPro/dbaseIII, this was a common issue...

I will add however that you often don't need the setwarnings anyway.

If you use the "execute" method in place of the docmd.runsql, then no
prompts, or warnings appear anyway.
In effect, you complete ignore those settings anyway.

currentdb.Execute "myquery or sql goes here"
 
D

David C. Holley

Still not an issue, just follow the calling statement with a
DoCmd.Warnings statemens to explicitiy set them once the external code
executes as in

call loadTransport
DoCmd.SetWarnings False

-or-
dteLastModified = getTransportLastModified()
DoCmd.SetWarnings False

There's no real overhead in adding the additional settings since its
just a value thats being set. By taking this approach, you're placing
the burden on the calling SUB or FUNCTION to ensure that the warnings
are in the state required by the calling SUB.

Of course the other alternative is to move to the .Execute method of the
Database object. When that method is used, the SQL statement will
execute MINUS warnings meaning that its up to you to provide the
warnings if desired which can be done by wrapping the .Execute method in
a transaction and rolling it back based on the value of a MsgBox
response. It is actually quite easy and places the burden on each
developer to determine wether or not to provide the warnings. It also
allows you to trap any errors that occurred.

David H
 
Top