Emiliano said:
Hello,
working with Vista Home Premium SP1 and Access 2003 SP3 and a level
secured database with workgroup information file, I got some problems
checking the CurrentUser property in "if/end if" blocks in the Form_Open
event to set some user-depending properties: the form opening does not
work! e.g. if I have the form open in design mode and try to run the form,
nothing happens - the form remains in design mode without errors claiming.
Sounds to me the simple solution here is to simply close the form first, and
then open it? In other words, don't flip from design to view mode. For
layout stuff etc it is certainly more convenient to switch between
design/view mode.
However you might want a clear up the above statement? It is not clear to me
if this view/design flip is you the developer, or your code doing this flip?
It is normal to flip design/view all the time. Using code to do this flip
is a 100% differnt issue.
Flipping forms/reports into design mode via code results in a
huge amount instability in your application.
I going to assume you doing the flip from design to view mode as a Developer
(and not by code). (but, you do need to correct me if my assumption is wrong
here).
So, if you have a problem form here and your code is messing with properties
of the form, then just save and close the form first and THEN try running
it. The on-open event does have things like the cancel event that will
PREVENT the form from loading. So, it just starts to make sense to avoid
the design/view flip and do a complete save here.
Think of a air plane. You can do a little bit of maintenance while the
airplane in flight. However, start doing more serious work on the plane,
and you simply need to get all the people off the plane, turn the engines
off etc. You can't do certain kinds of work while the plane is in flight.
The same goes for this form and modifying things.
Then I've choosen to follow another way to control the username and used
the CurrentUser property directly in a DoCmd.runsql statement.
This sounds like a different problem for different solution for a different
issue? Perhaps I misunderstand your first problem and issue? Now we talking
about running sql?
Is not clear how setting properties in the forms on-open event has any
relation to running some queries? Keep in mind that you CAN NOT modify the
values of any controls on a form in the forms on-open event (code that
modifies the actual values controls on the form action MUST be placed in the
forms on-load event...on open is TOO SOON to modify the values of controls).
So we have:
on-open event - this event can check for certain things and if we set
cancel = true the form will not load or display. At this point in time you
can check/read the "value" of a control, but you CAN NOT yet modify the
value of a bound control in the on-open event.
on-load event - this event occurs after the on open event, and at this
point your freely able to read or modify the values of those bound controls
on the form.
So, this event is also a good place where the setup and initialization
code for the form should go. In other words criteria and code in the on-open
event is used to PREVENT the form from opening. The next event is the
on-load event and it don't run unless the on-open event says so (of course
if you place nothing on open event, then your form will run and load as
usual).
You seem to say that when you're in design mode and flip into form view mode
it did not work. Was I wrong to assume that if you simply launch the form
when it already been closed and saved it worked ok?
To disable the warnings I thought to place two docmd.SetWarnings
False/True before and after the DoCmd.RunSQL but surprisingly the code
does'nt work. The code performs only if I delete the SetWarnings.
I don't use setwarmings but as a general rule run sql via
currentdb.execute "sql goes here",dbFailOnError
The above is not only less code, but also means you don't effect other
features and operation of the application (this is a specially so if you
forget to turn setwarnings back on). So as a general rule I would suggest
that you don't play with the set warnings unless you absolutely have to.
One last point, currentuser will always return "admin" unless you setup and
implemented user level security (so, I assume you setup and implemented uls
here).
