I found a lot of misunderstanding in this thread in the sense of "this
works" or "this does not work". I work with Access ADP 2000 plus SQL
Server. Let me give some hints:
- I could use statements like: rptActive.RecordSource =
"dbo.procMyReport".
Just do not state it in the Report_Open, but in the Report_Activate
event.
- I can stretch this idea a little bit further (but won't be too
specific):
"Always try the Report_Activate event (and NOT the Report_Open) for
data processing".
- It is correct to have input parameter specifications like:
"@Parm1 = Forms!frmHidden!Parm1, @Parm2 = Forms!frmHidden!Parm2".
Still, I think this is an awkward kind of programming. I made a Public
property and had a parameter specification like: "@Parm1 =
Forms!frmMyForm!MyProperty". What's the advantage:
- I do not need an additional form to reach my goal.
- Neither do I need an additional control somewhere. Make it a
property, that's a more parsimoneous (lightweight) approach.
- The above parameter specification works for a public property on an
open form, it dis not work for a public property in a standard module
(sorry, did not test yet for a property in a class).
Let me provide some more information. The most informative source for
this kind of questions is the widely-acclaimed Chipman and Byron
(2001). "Microsoft Access Developer's Guide to SQL Server". In their
chapter 12 on reports, they describe a few techniques that don't work
but should. I did not check every detail, but I found a few of their
non-working techniques working for me (in ADP as well as in ADE). My
guess for now: "It's the Report_Activate event that makes the
difference".
Leendert van Staalduinen,
van Staalduinen Data Management bv.
Mark Flippin <me******@comcast.net> wrote in message news:<71********************************@4ax.com>. ..
Randy,
That's exactly what I've decided to do (option 2, launch the report
frm the form to ensrue it's open). This works fine for the current
project.
Mark
On Tue, 14 Sep 2004 09:23:57 -0700,
"vtashore@Ta*********@adelphia.net" <vt******@adelphia.net> wrote:
Why not write the values of the input parameters into unbound text fields on
a hidden form at run time and have your report's input parameter refer to
the controls' properties? Alternately, launch the report from this form to
ensure that it is open.
@Parm1 = Forms!frmHidden!Parm1, @Parm2 = Forms!frmHidden!Parm2
Alternately, launch the report from this form to ensure that it is open.
Hope this helps.
Randy Shore