Is there a VBA refresh in an Access report??

  • Thread starter Thread starter PFMcCracken
  • Start date Start date
P

PFMcCracken

Someone brought up the point that when a VBA change is made and then re-run
in the MS Access report that the change in the code may not be seen and thus
you believe all your efforts are for naught. (nothing).

Is this true? And if so, how do I overcome this??

Philip
 
Someone brought up the point that
when a VBA change is made and
then re-run in the MS Access report
that the change in the code may not
be seen and thus you believe all your
efforts are for naught. (nothing).

Is this true? And if so, how do I
overcome this??

First, let me say that I do not find it necessary to use very much code in
Reports. I am not certain of the context of the statement you mention, so I
can't confirm or dispute that there are conditions where it may be accurate.
I am also not certain what you mean by "code may not be seen".

In Access 2000 and later, the VBA development environment used with the rest
of office, a "separate entity", replaced "Access Basic" or "Access VBA". In
the VBE (Visual Basic Environment) of Access 2000 and later, you can close a
module window without being prompted to save. Thus, it is possible that an
application crash, caused by an error in your VBA, can cause code changes
since the last Save to be lost. A countermeasure to that is to manually Save
after every code change. That should also ensure that the code change takes
effect and is executed when you next run the report.

In case anyone should wonder, no, I do not think it was a good idea to close
module windows without prompting for a save and have changes "floating
around in memory" instead of saved to disk.

I think I understand their reasoning, however: in earlier versions, you
changed and saved just the object on which you'd been working; with Access
2000, there is no such partial save... you are prompted which modules you
want/do not want to save... but the whole database/project is written to
disk when you save. I suspect they thought the "slow save" would be more
irritating than the "off-chance" of losing some changes in case of a (rare)
crash of VBA code.

Larry Linson
Microsoft Access MVP
 
Back
Top