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

[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.SetWarnin gs 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.

[Tom van Stiphout]

On Tue, 11 Mar 2008 21:10:26 -0400, MLH <CR**@NorthStat e.netwrote:

Simple: in a standard module create this:
private m_blnWarningSta te as Boolean
public sub SetWarningsOff( )
docmd.SetWarnin gs False
m_blnWarningSta te = False
end sub
public sub SetWarningsOn()
docmd.SetWarnin gs True
m_blnWarningSta te = True
end sub
public function GetWarningState () as Boolean
GetWarningState = m_blnWarningSta te
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.SetWarni ngs 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.

[Allen Browne]

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

On Tue, 11 Mar 2008 21:10:26 -0400, MLH <CR**@NorthStat e.netwrote:

Simple: in a standard module create this:
private m_blnWarningSta te as Boolean
public sub SetWarningsOff( )
docmd.SetWarnin gs False
m_blnWarningSta te = False
end sub
public sub SetWarningsOn()
docmd.SetWarnin gs True
m_blnWarningSta te = True
end sub
public function GetWarningState () as Boolean
GetWarningState = m_blnWarningSta te
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.SetWarn ings 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
deliberatel y 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.

[Tom van Stiphout]

On Wed, 12 Mar 2008 22:24:29 +0900, "Allen Browne"
<Al*********@Se eSig.Invalidwro te:

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

[frogsteaks]

On Mar 11, 9:10*pm, MLH <C...@NorthStat e.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.SetWarnin gs 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 ToggleWarningSt ate(bState as boolean)
DoCmd.SetWarnin gs bState
bWarningState = bState
end sub

public function CurrentWarningS tate() as Boolean
CurrentWarningS tate = bWarningState
end function

Similar to above with less code. Shoudl work just fine.

[Wayne Gillespie]

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*********@S eeSig.Invalidwr ote:

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