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

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.

On Tue, 11 Mar 2008 21:10:26 -0400, MLH <CRCI@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.

Quote:

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

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.spam.tom7744@cox.netwrote in message
news:dqhet3tb7l3lmoaqv22gv1pbts11qcji6a@4ax.com...

Quote:

On Tue, 11 Mar 2008 21:10:26 -0400, MLH <CRCI@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.
>
>

Quote:

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

On Wed, 12 Mar 2008 22:24:29 +0900, "Allen Browne"
<AllenBrowne@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.

Quote:

>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

On Mar 11, 9:10*pm, MLH <C...@NorthState.netwrote:

Quote:

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.

On Wed, 12 Mar 2008 07:15:29 -0700, Tom van Stiphout <no.spam.tom7744@cox.net>
wrote:

Quote:

>On Wed, 12 Mar 2008 22:24:29 +0900, "Allen Browne"
><AllenBrowne@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

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

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

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

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

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

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

/bytes/development

/bytes/it

/bytes/about