Check Status of SetWarnings

[Robert McEuen]

This is probably really simple, but I can't find a thread that
addresses it. Is there any way to evaluate in code whether the
current state of the SetWarnings command is set to True or False? I
have a Public Sub that I want to use from several areas of my
application, and I want to turn off warnings for it, but I don't want
to set warnings back to True if the sub was invoked from another sub
or function where warnings had already been set to False.

[PC Datasheet]

Your subs and functions that call the public sub should look like:

DoCmd.SetWarnings False
Call NameOfPublicSub
DoCmd.SetWarnings True

This code will branch to the public sub, execute it and then return to the line
below the Call statement. Therefore, Warnings will always be off when running
the public sub and then will be immediately turned back on when the public sub
is done.

--
PC Datasheet
Your Resource For Help With Access, Excel And Word Applications
re******@pcdatasheet.com
www.pcdatasheet.com

"Robert McEuen" <UN**********@yahoo.com> wrote in message
news:fb**************************@posting.google.c om...

This is probably really simple, but I can't find a thread that
addresses it. Is there any way to evaluate in code whether the
current state of the SetWarnings command is set to True or False? I
have a Public Sub that I want to use from several areas of my
application, and I want to turn off warnings for it, but I don't want
to set warnings back to True if the sub was invoked from another sub
or function where warnings had already been set to False.

[Salad]

Robert McEuen wrote:

This is probably really simple, but I can't find a thread that
addresses it. Is there any way to evaluate in code whether the
current state of the SetWarnings command is set to True or False? I
have a Public Sub that I want to use from several areas of my
application, and I want to turn off warnings for it, but I don't want
to set warnings back to True if the sub was invoked from another sub
or function where warnings had already been set to False.

Since it's not a property, more of a state performed by an action, I
doubt it. You might consider setting a global variable to track it.

[Allen Browne]

It is good coding to return a state to the way you found it, but Access does
not let you read the state of SetWarnings.

Your options are to maintain your own flag, or to avoid using SetWarnings.

If you are running action queries, consider using the Execute method (DAO)
instead of RunSQL. Execute does not pop up the warnings, so there is no need
to toggle SetWarnings. It is also more powerful:
- the dbFailOnError switch lets you opt out if there is an error (such as a
concurrency issue that does not allow the action query to complete);
- you have the option to use a transaction around the whole process for an
all-or-nothing result;
- you can read the number of records affected.

Example:
Dim db As DAO.Database
Dim strSQL As String

Set db = dbEngine(0)(0)
strSQL = "INSERT INTO ...

db.Execute strSQL, dbFailOnError
MsgBox db.RecordsAffected " record(s) inserted."

Set db =Nothing

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Robert McEuen" <UN**********@yahoo.com> wrote in message
news:fb**************************@posting.google.c om...

This is probably really simple, but I can't find a thread that
addresses it. Is there any way to evaluate in code whether the
current state of the SetWarnings command is set to True or False? I
have a Public Sub that I want to use from several areas of my
application, and I want to turn off warnings for it, but I don't want
to set warnings back to True if the sub was invoked from another sub
or function where warnings had already been set to False.

[Doug Hutcheson]

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:40**********************@freenews.iinet.net.a u...

It is good coding to return a state to the way you found it, but Access does not let you read the state of SetWarnings. <snip>
Well, well.
I though it was available under GetOptions / SetOptions, but I must have
been mistaken.
Is there really no collection which can be traversed to find this value?
"8-\
Cheers,
Doug

--
Remove the blots from my address to reply

[Allen Browne]

Let's know if you find one, Doug.

I gave up on SetWarnings in Access 2, for this very reason.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Doug Hutcheson" <do*****************@nrm.blot.qld.blot.gov.blot.au > wrote
in message
news:on***************@news.optus.net.au...

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:40**********************@freenews.iinet.net.a u...

It is good coding to return a state to the way you found it, but Access

does

not let you read the state of SetWarnings.

<snip>
Well, well.
I though it was available under GetOptions / SetOptions, but I must have
been mistaken.
Is there really no collection which can be traversed to find this value?
"8-\
Cheers,
Doug

[Doug Hutcheson]

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:40**********************@freenews.iinet.net.a u...

"Doug Hutcheson" <do*****************@nrm.blot.qld.blot.gov.blot.au > wrote
in message
news:on***************@news.optus.net.au...

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:40**********************@freenews.iinet.net.a u...

It is good coding to return a state to the way you found it, but

Access does

not let you read the state of SetWarnings.

<snip>
Well, well.
I though it was available under GetOptions / SetOptions, but I must have
been mistaken.
Is there really no collection which can be traversed to find this value?
"8-\
Cheers,
Doug

Let's know if you find one, Doug.

I gave up on SetWarnings in Access 2, for this very reason.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

OK all you MVPs: what API needs to be called to read this value? It's gotta
be there somewhere in order to have effect!
<I never give up without a drink ... er ... fight ... >
"8-]

--
Remove the blots from my address to reply

[Salad]

Doug Hutcheson wrote:

Let's know if you find one, Doug.

I gave up on SetWarnings in Access 2, for this very reason.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

OK all you MVPs: what API needs to be called to read this value? It's gotta
be there somewhere in order to have effect!
<I never give up without a drink ... er ... fight ... >
"8-]

Just as you can "set warning False" in a form by simply entering
Response = acdataerrcontinue
in the forms' OnError event, I would think there is a flag somewhere
within access that gets set that when running a query or whatever tells
the system not to display a message. Instead of an API, I guessing the
flag gets set somewhere in a system table.

[Ian Hinson]

"Doug Hutcheson" <do*****************@nrm.blot.qld.blot.gov.blot.au > wrote
in message news:_C***************@news.optus.net.au...

OK all you MVPs: what API needs to be called to read this value? It's gotta be there somewhere in order to have effect!

I'm not an MVP but ...
The OP can get around his problem by using:

Application.SetOption "Confirm Action Queries", False
DoCmd.RunSQL "UPDATE table1 (etc)"
Application.SetOption "Confirm Action Queries", True

This preserves the SetWarnings state for when the Option is set back to
True.
Also, by setting the Option to False its overrides any previous SetWarnings
= True such that no warnings are given.

Ian Hinson.

[Michael \(michka\) Kaplan [MS]]

However, this will break any user who had that setting as being False
already themselves?
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
"Ian Hinson" <pp******@bigpond.net.au> wrote in message
news:0W*****************@news-server.bigpond.net.au...

"Doug Hutcheson" <do*****************@nrm.blot.qld.blot.gov.blot.au > wrote
in message news:_C***************@news.optus.net.au...

OK all you MVPs: what API needs to be called to read this value? It's gotta

be there somewhere in order to have effect!

I'm not an MVP but ...
The OP can get around his problem by using:

Application.SetOption "Confirm Action Queries", False
DoCmd.RunSQL "UPDATE table1 (etc)"
Application.SetOption "Confirm Action Queries", True

This preserves the SetWarnings state for when the Option is set back to
True.
Also, by setting the Option to False its overrides any previous

SetWarnings = True such that no warnings are given.

Ian Hinson.

[Ian Hinson]

"Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com> wrote in
message news:40********@news.microsoft.com...

However, this will break any user who had that setting as being False
already themselves?

In my example code I made a point of setting the option back to true using:
Application.SetOption "Confirm Action Queries", True
immediately after running the query so as to restore the effect of whatever
the current SetWarnings setting may be, in line with the OP's original
question.

But if, as you suggest, some other programmer may abuse that principle by
leaving the Option in a False state, then it's already "game over" whichever
way you look at it.

Ian.

--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
"Ian Hinson" <pp******@bigpond.net.au> wrote in message
news:0W*****************@news-server.bigpond.net.au...

"Doug Hutcheson" <do*****************@nrm.blot.qld.blot.gov.blot.au > wrote in message news:_C***************@news.optus.net.au...

OK all you MVPs: what API needs to be called to read this value? It's

gotta

be there somewhere in order to have effect!

I'm not an MVP but ...
The OP can get around his problem by using:

Application.SetOption "Confirm Action Queries", False
DoCmd.RunSQL "UPDATE table1 (etc)"
Application.SetOption "Confirm Action Queries", True

This preserves the SetWarnings state for when the Option is set back to
True.
Also, by setting the Option to False its overrides any previous

SetWarnings

= True such that no warnings are given.

Ian Hinson.

[Michael \(michka\) Kaplan [MS]]

Ian,

Did you read my post? What if their setting was False there? Your code will
stomp on their setting.

Which explains why SetWarnings is GOOD -- because you know if you set it --
so you can unset it. Why muck with user settings when there is such an easy
way to avoid it?
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.

"Ian Hinson" <pp******@bigpond.net.au> wrote in message
news:HA*****************@news-server.bigpond.net.au...

"Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com> wrote in
message news:40********@news.microsoft.com...

However, this will break any user who had that setting as being False
already themselves?

In my example code I made a point of setting the option back to true

using: Application.SetOption "Confirm Action Queries", True
immediately after running the query so as to restore the effect of whatever the current SetWarnings setting may be, in line with the OP's original
question.

But if, as you suggest, some other programmer may abuse that principle by
leaving the Option in a False state, then it's already "game over" whichever way you look at it.

Ian.

--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
"Ian Hinson" <pp******@bigpond.net.au> wrote in message
news:0W*****************@news-server.bigpond.net.au...

"Doug Hutcheson" <do*****************@nrm.blot.qld.blot.gov.blot.au > wrote in message news:_C***************@news.optus.net.au...

> OK all you MVPs: what API needs to be called to read this value? It's gotta
> be there somewhere in order to have effect!

I'm not an MVP but ...
The OP can get around his problem by using:

Application.SetOption "Confirm Action Queries", False
DoCmd.RunSQL "UPDATE table1 (etc)"
Application.SetOption "Confirm Action Queries", True

This preserves the SetWarnings state for when the Option is set back to True.
Also, by setting the Option to False its overrides any previous

SetWarnings

= True such that no warnings are given.

Ian Hinson.

[Ian Hinson]

MichKa,

Did you read my post? Yep.
What if their setting was False there? Then SetWarnings has NO effect, and is ignored by Access.
(ie. No warnings are given, even if SetWarnings = On)
Your code will stomp on their setting. This could be easily overcome by calling GetOption first,
then restoring it to its original state afterwards (if that is any real
concern).
The OP wanted to retain the effect of SetWarnings which made me assume that
the option (Confirm Action Queries) was already in a True state in the first
place.
Which explains why SetWarnings is GOOD
-- because you know if you set it --
so you can unset it.
Good, apart from these limitations:
1) You can't read back what its current state is.
2) It is meaningless if the Confirm Action Queries option is False.
Why muck with user settings when there is such an easy
way to avoid it?
Well yes, the whole "problem" could have been avoided in the first place if
the OP had followed a simple rule:-
Always set SetWarnings to the required state immediately before running a
query, and never ASSUME it has been left is some state by some other
previous process.
(Not that I saw anyone offer this advice to the OP.)

Ian.

--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.

"Ian Hinson" <pp******@bigpond.net.au> wrote in message
news:HA*****************@news-server.bigpond.net.au...

"Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com> wrote in
message news:40********@news.microsoft.com...

However, this will break any user who had that setting as being False
already themselves?

In my example code I made a point of setting the option back to true

using:

Application.SetOption "Confirm Action Queries", True
immediately after running the query so as to restore the effect of

whatever

the current SetWarnings setting may be, in line with the OP's original
question.

But if, as you suggest, some other programmer may abuse that principle by

leaving the Option in a False state, then it's already "game over"

whichever

way you look at it.

Ian.

--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
"Ian Hinson" <pp******@bigpond.net.au> wrote in message
news:0W*****************@news-server.bigpond.net.au...
> "Doug Hutcheson" <do*****************@nrm.blot.qld.blot.gov.blot.au >

wrote

> in message news:_C***************@news.optus.net.au...
>
> > OK all you MVPs: what API needs to be called to read this value?

It's > gotta
> > be there somewhere in order to have effect!
>
> I'm not an MVP but ...
> The OP can get around his problem by using:
>
> Application.SetOption "Confirm Action Queries", False
> DoCmd.RunSQL "UPDATE table1 (etc)"
> Application.SetOption "Confirm Action Queries", True
>
> This preserves the SetWarnings state for when the Option is set back to > True.
> Also, by setting the Option to False its overrides any previous
SetWarnings
> = True such that no warnings are given.
>
> Ian Hinson.
>
>

[Michael \(michka\) Kaplan [MS]]

"Ian Hinson" <pp******@bigpond.net.au> wrote...

Good, apart from these limitations:
1) You can't read back what its current state is.
Which does not matter; like I said, you know if you set it.
2) It is meaningless if the Confirm Action Queries option is False.
Which also does not matter. Pretend it is called
"SetWarningsIfTheyAreSetElsewhere" and then you will know what it is doing.
Its not a bug, its behaving as expected.

<snip solution>
(Not that I saw anyone offer this advice to the OP.)

Actually, people did, in pointing out that it does not matter if it has been
set, etc.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.