The fact that the main report is activated by a form doesn't necessarily
mean that only one record will be printed. I have many reports here
activated by forms who are printing more than one single record each time.
But if your main report does *always* print a *single* record then yes, some
technics that won't work in the general case of printing multiple records -
particularly for subreports - will now work correctly in this particular
case. If your main report print only a single record and the subreport
print only the same record with the same then I suppose (but I'm not sure
because I never tried it personally) that yes, you can use the
InputParameters for the subreport as well by using the exact same parameter.
However, if later you want to print multiples records, don't be surprised it
this method don't work anymore for the subreport.
For your second problem about the same report to be print by two different
forms, you can use either an hidden form - as you have already suggested
yourself - or use public variables in the module of the report. You must
populate these variables in the OnOpen event of the report - for example by
using the OpenArgs parameter to pass the name of the form from which to read
the values to be used. I suppose that there is other methods but I didn't
check. Don't forget that these variables must be public - otherwise they
won't be accessible - and that you must use the Reports collection and not
the Forms collection is you want to make a reference to them in the
InputParameters property.
Are you are not opening the report in design mode, both of these technics
should work well in the case of ADE too. Here an exemple of the code for
the report:
Public IdRoute As Integer
Private Sub Report_Open(Cancel As Integer)
If (IsNull(Me.OpenArgs)) Then
MsgBox "This report cannot be opened directly."
Cancel = True
Exit Sub
End If
' IdRoute is the name of a control on the form(s):
IdRoute = Forms(Me.OpenArgs)!IdRoute
End Sub
and for the InputParameters property:
@IdRoute int = Reports!NameOfYourReport.IdRoute
and for calling this report:
On Error Resume Next
DoCmd.OpenReport "NameOfYourReport", acViewPreview, , , , Me.name
On Error GoTo 0
Also, if I remember correctly, the OpenArgs parameter was not available for
reports in A2000; so you won't find a mention of it in your book.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
amg51 said:
No I have have 2 different main reports which use exactly the same
subreport.
The main reports are activated by a form so that (normally) only one
record
( Order) is printed.
The main form is based on a stored procedure with a paramete(orderId)
The subform is also based on a stored procedure ( with the same parameter
_
OrderId)
My original question was to try and find out the correct and speediest
way
of specifying the data for the subreport- i.e link fields, or specify
Input
parameters or what. I now understand what you mean about Access creating
it's own Input Parameter for the subreport. But does that mean the link
fields need to be filled ( with OrderId) or are irrelevant.
I have another problem in that two different forms activate the same
report
( again to print only one record). This brings into play the book
reference
which suggested that you could not specify the Input Parameter at Run
Time.
Pretty obviously you cannot invoke design mode if you are hoping to use
the
Run time system ( which is currently a no go anyway - since everything
based
directly on stored procedures - combo boxes, record sources - do not work)
Sorry for putting it in the wrong forum - maybe some kind soul will
transfer
it.
Sylvain Lafontaine said:
There is no confusion, I never said in c) ... that the InputParameters
must
be set for subreports. The InputParameters is to be used for the main
report(s) and not with subreports. (Maybe the InputParameters can work
with
subreports, I don't know, I never tried).
The easiest way to work with subreports is not to use the
InputParameters:
it must be left blank. I'm talking here about the InputParameters of the
subreport and not the InputParameter of the main report.
It looks like that you are making a confusion between the InputParameters
of
the main report and the InputParameters of the subreport. Are you trying
to
use a report both as a main report and also as a subreport?
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
Now you are confusing me - previously when you answered the question
about
subreports you said
"In my opinion, the best way with subreport is c) Use a stored
procedure
whose parameters have the same names as one or more fields of the
parent
report (less the @). For example, if the source of the parent is:
Select IdSchool, SchoolName from ...
then the parameter « @IdSchool int » would be perfect for the
subreport.
Now you are saying the Input parameter should be left blank."
I used a Stored procedure for the subreport
@Orderid int = Reports!Mainform.Orderid and it seemed to work fine
:
For the notice in the book, I suppose that this was true for ADP 2000
but
these things now work properly with A2003 (and probably with A2007 but
I
didn't make a test). For the subreport, you don't use the
InputParameters
at all; it must be left blank.
If the stored procedure for the subreport has a parameter named
@OrderId,
ADP will make automatically the association with the field OrderId of
the
main report's recordsource if this field is bound to a control; this
control
might be hidden. To be sure, I always give the control the same name
as
the
field.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
Sorry should be page 616 ( starts on page 615 - "Techniques that
don't
work
but should")
Your second comment about subreports: I used your advice about
referring
to
a control on the main report - thank you very much.
@orderid int = Reports!Mainreport.Orderid
That works fine - But what happens if you want to use the SAME
subreport
with DIFFERENT main reports.
:
There is nothing about the InputParameters and Reports on page 416
in
this
book. The section about reports begin on page 599 and there is no
mention
that you cannot change this property in the OnReport event.
However,
when
changing this property in the OnReport event, you must *not* switch
from
Design View to Preview or Print mode; you must really open the
report;
ie
must be closed before that and not be in Design View. Using public
variables on the report should also work well and would be easier
than
using
an hidden form. Note that with public variables on a report, you
must
use
Reports and not Forms as the collection in the InputParameters
property:
@Id
int = Reports!MyReport.MyVariable
For the subreport, use parameters that have the same name (minus
the
@)
as
fields in the recordsource of the parent report. These fields must
also
be
bound to (hidden) controls on the parent report. Personally, I
always
gives
the controls the same name as their underlying bound field; don't
remember
if it's important. This is the easiest way to work with subreport.
In
my
opinion, things like @orderID int = Me.parent.orderid shouldn't
work
for
subreports.
Finally, the newsgroup for ADP is m.p.a.adp.sqlserver.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
If a report is based on a Stored Procedure it seems that you
cannot
change
the
Input Parameter at Report Open - you need to (statically) point
it
at a
control on a form. ( See Microsoft Access Developer's Guide to
SQL
Server
p416)
How then would you open a report from 2 different forms ( except
maybe
by
creating another[Hidden] form to act as an intermediary?
Similarly if you have a subreport used in more than one report -
the
way
that works well is to set the Input parameters for the subreport
Stored
procedure to refer to a field on the main report. Are you
allowed
syntax
like @orderID int = Me.parent.orderid
