Supressing warnings

  • Thread starter Thread starter Rick
  • Start date Start date
R

Rick

Is there ANY way to suppress warnings and messages
displayed to the user when queries are run? I need to hide
messages like "You are about to update X rows in running
this query is that OK?" I basically need to find a way to
FORCE the queries to be executed behind the scenes without
the users being bothered with the details. I have a
series of update, append and Delete Queries that all
inevitably trigger these messages and if a user selects
the wrong option many problems are experienced. I need
rid of them (not the users, I wish that were a solution;)

I am performing these via the docmd.openquery method and
have the queries pre-create. I set the queries to run
acview normal since they do not actually SHOW anything
they only copy data or delete it.

I am using Access 97.

Rick
 
Rick said:
Is there ANY way to suppress warnings and messages
displayed to the user when queries are run? I need to hide
messages like "You are about to update X rows in running
this query is that OK?" I basically need to find a way to
FORCE the queries to be executed behind the scenes without
the users being bothered with the details. I have a
series of update, append and Delete Queries that all
inevitably trigger these messages and if a user selects
the wrong option many problems are experienced. I need
rid of them (not the users, I wish that were a solution;)

I am performing these via the docmd.openquery method and
have the queries pre-create. I set the queries to run
acview normal since they do not actually SHOW anything
they only copy data or delete it.

I am using Access 97.

Don't use DoCmd.OpenQuery. Instead use...

CurrentDB.Execute "QueryName", dbFailOnError
 
' (Optional: doing it the right way) Store the user's current Option
settings:
' Note: using a Long type is overkill in this case but not for other Option
settings
lngSettingRC = Application.GetOption("Confirm Record Changes")
lngSettingAQ = Application.GetOption("Confirm Action Queries")

' *** Turn confirmations off: (0 = Off/False, -1 = On/True) ***
Application.SetOption "Confirm Record Changes", 0
Application.SetOption "Confirm Action Queries", 0

' *** Run your queries

' (Optional: doing it the right way) Restore user's original Option
settings:
Application.SetOption "Confirm Record Changes", lngSettingRC
Application.SetOption "Confirm Action Queries", lngSettingAQ
 
Sorry to disagree, Alex, but I think it's better to use the Execute method
than futzing around with SetWarnings.

Dim dbCurr As DAO.Database
Dim qdfCurr As DAO.QueryDef

Set dbCurr = CurrentDb()
Set qdfCurr = dbCurr.QueryDefs("MyActionQuery")
qdfCurr.Execute, dbFailOnError

This is possible even if you don't have the query prestored:

Dim dbCurr As DAO.Database
Dim qdfCurr As DAO.QueryDef
Dim strSQL As String

strSQL = "DELETE FROM..."

Set dbCurr = CurrentDb()
Set qdfCurr = dbCurr.CreateQueryDef("", strSQL)
qdfCurr.Execute, dbFailOnError
 
Hi Doug,
agree it is better then docmd.runsql in most cases, but I meant that better
to use SetWarnings then setoption

:-)
 
Actually, I use GetOption/SetOption etc., once at the App StartUp and then
reset SetOption to the user's original settings upon App Close. Then I
don't have to worry about it again for the duration unless I chose to
generate my own warning. (and there are several other settings that are
handled similarly at the same time.)

I realize my answer could be misleading since this isn' t exactly what the
OP was asking about and your points are well taken.
 
Hi George,
i see, but you should aware that if your application hangs and will be
closed without App Close - option will remain as you set it in startup, so
other access apps will run without warnings
 
Thanks, I am aware of that.

I save these settings (and several others, including a
"PreviousSessionClosedProperly" flag) in the registry. If the previous
session ended badly I do not overwrite the option settings stored in the
registry, otherwise I do. On AppClose Options are reset to the stored
values, whatever they may be.

I admit that this doesn't help *other* Access apps run during the interim,
but that isn't currently an issue.
 
Back
Top