MichKa,
[color=blue]
> Did you read my post?[/color]
Yep.
[color=blue]
> What if their setting was False there?[/color]
Then SetWarnings has NO effect, and is ignored by Access.
(ie. No warnings are given, even if SetWarnings = On)
[color=blue]
> Your code will stomp on their setting.[/color]
This could be easily overcome by calling GetOption first,
then restoring it to its original state afterwards (if that is any real
concern).
The OP wanted to retain the effect of SetWarnings which made me assume that
the option (Confirm Action Queries) was already in a True state in the first
place.
[color=blue]
> Which explains why SetWarnings is GOOD
> -- because you know if you set it --
> so you can unset it.[/color]
Good, apart from these limitations:
1) You can't read back what its current state is.
2) It is meaningless if the Confirm Action Queries option is False.
[color=blue]
> Why muck with user settings when there is such an easy
> way to avoid it?[/color]
Well yes, the whole "problem" could have been avoided in the first place if
the OP had followed a simple rule:-
Always set SetWarnings to the required state immediately before running a
query, and never ASSUME it has been left is some state by some other
previous process.
(Not that I saw anyone offer this advice to the OP.)
Ian.
[color=blue]
>
> --
> MichKa [MS]
> NLS Collation/Locale/Keyboard Development
> Globalization Infrastructure and Font Technologies
>
> This posting is provided "AS IS" with
> no warranties, and confers no rights.
>
>
>
> "Ian Hinson" <pparagon@bigpond.net.au> wrote in message
> news:HAmwc.7347$rz4.6678@news-server.bigpond.net.au...[color=green]
> > "Michael (michka) Kaplan [MS]" <michkap@online.microsoft.com> wrote in
> > message news:40c1e482$1@news.microsoft.com...[color=darkred]
> > > However, this will break any user who had that setting as being False
> > > already themselves?
> > >[/color]
> >
> > In my example code I made a point of setting the option back to true[/color]
> using:[color=green]
> > Application.SetOption "Confirm Action Queries", True
> > immediately after running the query so as to restore the effect of[/color]
> whatever[color=green]
> > the current SetWarnings setting may be, in line with the OP's original
> > question.
> >
> > But if, as you suggest, some other programmer may abuse that principle[/color][/color]
by[color=blue][color=green]
> > leaving the Option in a False state, then it's already "game over"[/color]
> whichever[color=green]
> > way you look at it.
> >
> > Ian.
> >[color=darkred]
> > >
> > > --
> > > MichKa [MS]
> > > NLS Collation/Locale/Keyboard Development
> > > Globalization Infrastructure and Font Technologies
> > >
> > > This posting is provided "AS IS" with
> > > no warranties, and confers no rights.
> > >
> > >
> > > "Ian Hinson" <pparagon@bigpond.net.au> wrote in message
> > > news:0W8wc.6358$rz4.3076@news-server.bigpond.net.au...
> > > > "Doug Hutcheson" <doug.blot.hutcheson@nrm.blot.qld.blot.gov.blot.au >[/color]
> > wrote[color=darkred]
> > > > in message news:_CSvc.51$EP1.2695@news.optus.net.au...
> > > >
> > > > > OK all you MVPs: what API needs to be called to read this value?[/color][/color]
> It's[color=green][color=darkred]
> > > > gotta
> > > > > be there somewhere in order to have effect!
> > > >
> > > > I'm not an MVP but ...
> > > > The OP can get around his problem by using:
> > > >
> > > > Application.SetOption "Confirm Action Queries", False
> > > > DoCmd.RunSQL "UPDATE table1 (etc)"
> > > > Application.SetOption "Confirm Action Queries", True
> > > >
> > > > This preserves the SetWarnings state for when the Option is set back[/color][/color]
> to[color=green][color=darkred]
> > > > True.
> > > > Also, by setting the Option to False its overrides any previous
> > > SetWarnings
> > > > = True such that no warnings are given.
> > > >
> > > > Ian Hinson.
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]
