Difference between Set warnings off and setting GetOption(Confirm Action Queries) to false
is there a different in functionailty between Set Warnings off, that is, do not want to see results of action queries as opposed to using Application.SetOption "Confirm Action Queries", False? This is an Access 2003 database.
Sandra
Sandra
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
"Opposed to using Application.SetOption "Confirm Action Queries", False? "
I suggest you leave those options checked, as they are global ... and dangerous to turn off. You can control all of this at the Form level.
Instead of DoCmd.SetWarnings False ... to avoid the message, use
CurrentDb.Execute "YourActionQueryName", dbFailOnError.
This is MUCH safer. No message AND ... you can trap an error that you WILL want to know about should it occur ... by using the dbFailOnError option.
mx
I suggest you leave those options checked, as they are global ... and dangerous to turn off. You can control all of this at the Form level.
Instead of DoCmd.SetWarnings False ... to avoid the message, use
CurrentDb.Execute "YourActionQueryName", dbFailOnError.
This is MUCH safer. No message AND ... you can trap an error that you WILL want to know about should it occur ... by using the dbFailOnError option.
mx
ASKER
Thank you both. This explains a few things. So, let me reiterate so I know I understand:
Confirm Action will stay on the user's computer so if I have this in code and set it, to reverse it would either have to be done again in code or I would actually have to physically visit the user's computer.
dbFailOnError is a much better way than using Set Warnings. Now, this should work whether I set a strSelect statement in code (strSelect = "DELETE * FROM sometable") as opposted to the fully statement that is:
CurrentDb.Execute strSelect, dbFailOnError
Currentdb.Execute "DELETE * FROM sometable", dbFailOnError
are the same statement. However, using this approach, I can trap errors rather than being in limbo using Set Warnings in code.
Sandra
Confirm Action will stay on the user's computer so if I have this in code and set it, to reverse it would either have to be done again in code or I would actually have to physically visit the user's computer.
dbFailOnError is a much better way than using Set Warnings. Now, this should work whether I set a strSelect statement in code (strSelect = "DELETE * FROM sometable") as opposted to the fully statement that is:
CurrentDb.Execute strSelect, dbFailOnError
Currentdb.Execute "DELETE * FROM sometable", dbFailOnError
are the same statement. However, using this approach, I can trap errors rather than being in limbo using Set Warnings in code.
Sandra
"dbFailOnError is a much better way than using Set Warnings. "
Well, the Execute Method is the better way. dbFailOnError insure that an error you likely care about will be raised. SetWarnings False masks ALL errors, even ones you want to know about.
" Now, this should work whether I set a strSelect statement in code"
Yes ...Query name or SQL string that represents an Action query.
SetOptions are temporary per Access session on a given computer. They are a convenient way to override default option settings.
mx
Well, the Execute Method is the better way. dbFailOnError insure that an error you likely care about will be raised. SetWarnings False masks ALL errors, even ones you want to know about.
" Now, this should work whether I set a strSelect statement in code"
Yes ...Query name or SQL string that represents an Action query.
SetOptions are temporary per Access session on a given computer. They are a convenient way to override default option settings.
mx
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
" Because it persists beyond the application"
Not sure what you mean by that ...?
Not sure what you mean by that ...?
ASKER
Yes, I want to catch the error and return them so I know what is going on. The dbFailOnError, as you explained, will let me know this. <br /><br />As for setting in code, I was a little perplexed by this as the code I inherited did this repeatedly, setting and then changing the setting back (or sometimes not). Thank you both.<br /><br />Sandra
Confirm Action Queries persists on the user's computer despite restarting.