By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,121 Members | 1,706 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,121 IT Pros & Developers. It's quick & easy.

What would you recommend as a harmless test to determine state of SetWarnings in A97

P: n/a
MLH
Access 97 does not provide a means of reading the
most recent setting for SetWarnings Method. For
example, if you had CBF that called a procedure in
a global module and the following statement was
executed:

DoCmd.SetWarnings False

Then you would not be able to take peek at the
setting when processing returned to the calling
procedure. You'd simply have to run the Method
there again to make sure the setting is what you
want it to be from that point forward.

I'm not saying there's anything wrong with that.
One can simply adapt. What is unhandy about not
being able to read the setting? Well, if you are
deliberately trying to identify and correct instances
where the setting is not what you intended for it to
be after calling some saved procedure.

I'd like to have a procedure that did something
trivial - something with no adverse effect that
when called, would do something that could
determine the setting - indirectly perhaps. Then
I could sprinkle my code with calls to this procedure
as liberally as I wanted. At some point I would be
satisfied, I'm sure, that SetWarnings settings made
in called procedures did not leave things in an
unexpected state upon return to the calling
procedure.
Mar 12 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
On Tue, 11 Mar 2008 21:10:26 -0400, MLH <CR**@NorthState.netwrote:

Simple: in a standard module create this:
private m_blnWarningState as Boolean
public sub SetWarningsOff()
docmd.SetWarnings False
m_blnWarningState = False
end sub
public sub SetWarningsOn()
docmd.SetWarnings True
m_blnWarningState = True
end sub
public function GetWarningState() as Boolean
GetWarningState = m_blnWarningState
end function

-Tom.

>Access 97 does not provide a means of reading the
most recent setting for SetWarnings Method. For
example, if you had CBF that called a procedure in
a global module and the following statement was
executed:

DoCmd.SetWarnings False

Then you would not be able to take peek at the
setting when processing returned to the calling
procedure. You'd simply have to run the Method
there again to make sure the setting is what you
want it to be from that point forward.

I'm not saying there's anything wrong with that.
One can simply adapt. What is unhandy about not
being able to read the setting? Well, if you are
deliberately trying to identify and correct instances
where the setting is not what you intended for it to
be after calling some saved procedure.

I'd like to have a procedure that did something
trivial - something with no adverse effect that
when called, would do something that could
determine the setting - indirectly perhaps. Then
I could sprinkle my code with calls to this procedure
as liberally as I wanted. At some point I would be
satisfied, I'm sure, that SetWarnings settings made
in called procedures did not leave things in an
unexpected state upon return to the calling
procedure.
Mar 12 '08 #2

P: n/a
Since Access does not provide a way to test this setting, Tom's suggestion
makes good sense.

A more fundamental question might be why you need to set this. IME, people
turn this off to suppress the messages when running action queries. That's
not a good idea: you have no idea whether the action query worked or ran
into errors.

A better solution (which avoids the need to mess with SetWarnings) might be
to use Exeucte with the action query:
http://allenbrowne.com/ser-60.html

--
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.

"Tom van Stiphout" <no*************@cox.netwrote in message
news:dq********************************@4ax.com...
On Tue, 11 Mar 2008 21:10:26 -0400, MLH <CR**@NorthState.netwrote:

Simple: in a standard module create this:
private m_blnWarningState as Boolean
public sub SetWarningsOff()
docmd.SetWarnings False
m_blnWarningState = False
end sub
public sub SetWarningsOn()
docmd.SetWarnings True
m_blnWarningState = True
end sub
public function GetWarningState() as Boolean
GetWarningState = m_blnWarningState
end function

-Tom.

>>Access 97 does not provide a means of reading the
most recent setting for SetWarnings Method. For
example, if you had CBF that called a procedure in
a global module and the following statement was
executed:

DoCmd.SetWarnings False

Then you would not be able to take peek at the
setting when processing returned to the calling
procedure. You'd simply have to run the Method
there again to make sure the setting is what you
want it to be from that point forward.

I'm not saying there's anything wrong with that.
One can simply adapt. What is unhandy about not
being able to read the setting? Well, if you are
deliberately trying to identify and correct instances
where the setting is not what you intended for it to
be after calling some saved procedure.

I'd like to have a procedure that did something
trivial - something with no adverse effect that
when called, would do something that could
determine the setting - indirectly perhaps. Then
I could sprinkle my code with calls to this procedure
as liberally as I wanted. At some point I would be
satisfied, I'm sure, that SetWarnings settings made
in called procedures did not leave things in an
unexpected state upon return to the calling
procedure.
Mar 12 '08 #3

P: n/a
On Wed, 12 Mar 2008 22:24:29 +0900, "Allen Browne"
<Al*********@SeeSig.Invalidwrote:

I agree. The only positive thing about DoCmd.RunSQL and its cousins is
that they provide a progress meter, whereas .Execute does not.

Don't forget to run .Execute with the dbFailOnError flag, in most
cases.

-Tom.

>Since Access does not provide a way to test this setting, Tom's suggestion
makes good sense.

A more fundamental question might be why you need to set this. IME, people
turn this off to suppress the messages when running action queries. That's
not a good idea: you have no idea whether the action query worked or ran
into errors.

A better solution (which avoids the need to mess with SetWarnings) might be
to use Exeucte with the action query:
http://allenbrowne.com/ser-60.html
Mar 12 '08 #4

P: n/a
On Mar 11, 9:10*pm, MLH <C...@NorthState.netwrote:
Access 97 does not provide a means of reading the
most recent setting for SetWarnings Method. For
example, if you had CBF that called a procedure in
a global module and the following statement was
executed:

DoCmd.SetWarnings False

Then you would not be able to take peek at the
setting when processing returned to the calling
procedure. You'd simply have to run the Method
there again to make sure the setting is what you
want it to be from that point forward.

I'm not saying there's anything wrong with that.
One can simply adapt. What is unhandy about not
being able to read the setting? Well, if you are
deliberately trying to identify and correct instances
where the setting is not what you intended for it to
be after calling some saved procedure.

I'd like to have a procedure that did something
trivial - something with no adverse effect that
when called, would do something that could
determine the setting - indirectly perhaps. Then
I could sprinkle my code with calls to this procedure
as liberally as I wanted. At some point I would be
satisfied, I'm sure, that SetWarnings settings made
in called procedures did not leave things in an
unexpected state upon return to the calling
procedure.

private bWarningState as Boolean

public sub ToggleWarningState(bState as boolean)
DoCmd.SetWarnings bState
bWarningState = bState
end sub

public function CurrentWarningState() as Boolean
CurrentWarningState = bWarningState
end function

Similar to above with less code. Shoudl work just fine.
Mar 12 '08 #5

P: n/a
On Wed, 12 Mar 2008 07:15:29 -0700, Tom van Stiphout <no*************@cox.net>
wrote:
>On Wed, 12 Mar 2008 22:24:29 +0900, "Allen Browne"
<Al*********@SeeSig.Invalidwrote:

I agree. The only positive thing about DoCmd.RunSQL and its cousins is
that they provide a progress meter, whereas .Execute does not.

Don't forget to run .Execute with the dbFailOnError flag, in most
cases.

-Tom.
I agree .Execute is generally the preferred method, however because DoCmd.RunSQL
is executed via the Access expression service rather than the Jet expression
service (used by Execute), their are instances where an SQL string will fail
using .Execute but will suceed using RunSQL.

Notably DoCmd.RunSQL can usually handle calls to custom functions within the SQL
string without having to concatenate the result of the function into the string
first.
Wayne Gillespie
Gosford NSW Australia
Mar 12 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.