unbound subreport with its own bound subreports throw an "enter parameter value" (error)

[markjkubicki]

I have a report (srptFixtureSchedule_text) with (2) subreports (srptAddlMfrs and srptInstallNotes); they are linked by the common field txtType (or otherwise stated in their queries as: Reports![srptFixtureSchedule_text].[txtType]

the report displays properly with no errors
(I should also point out that the subreports may have no records related records in which case, they do not display at all (for that record) - this may be of no relevance, but I though ti ought to at least mention it...

the problem is:
when I create a BLANK new report: rptFixtureSchedule_shell with srptFixtureSchedule_text as an UNBOUND subreport, I get prompted for report parameters: Reports!rptFixtureSchedule_text.txtType


clicking thru the prompts eventually get thru to the report; however, the subreports (srptAddlMfrs and srptInstallNotes) are not displayed (?!)

?HUH?
I don't get it...

any suggestion will be greatly appreciated in advance,
Mark

[amrut]

(or otherwise stated in their queries as: Reports![srptFixtureSchedule_text].[txtType]

The parameters/criteria to pull selective data from table(s) should be passed using forms and not report.

when I create a BLANK new report: rptFixtureSchedule_shell with srptFixtureSchedule_text as an UNBOUND subreport

Typically, some fields in report may be unbound and values assigned dynamically but generally, reports are based on some query or table.
The parameter pops up because the report rptFixtureSchedule_text is inside the report rptFixtureSchedule_shell.
Try

Reports!rptFixtureSchedule_shell!srptFixtureSchedule_text.Report.txtType

In this case the, syntax to refer to the control on sub-report will be different. See more for syntax http://access.mvps.org/access/forms/frm0031.htm
The link refers to sub-forms.

[markjkubicki]

about " parameters/criteria to pull selective data from table(s) should be passed using forms and not report.using forms not report."
not certain where I'm wrong ( I might indeed be doing the right thing, but stating it incorrectly (?) ); where the "query" exists is in the data property of the report (?) But for now, that doesn't seem to be the problem (?)

but going on...
your suggestion to change the parameter to: Reports!rptFixtureSchedule_shell!srptFixtureSchedu le_text.Report.txtType
worked in that the subreports now displays exactly correct;
however, now the (textbox) controls in the detail section of the report (which is where the subreports are...), which previously displayed correctly are now empty
(their values are strings that are compiled in VBA and the assigned to the text boxes)

regardless...
by changing the paremeter, the very problem that I was hoping to deal with returns:

the contents of srtFixtureSchedule_text have a not insignificant amount of code behind them, and we have a need for several different "print formats" (for the most part, different versions of footers, headers, and margins) (the report fits into documents "by others", and it is important for the overall "look" of my document to match theirs....

I was hoping to create a library of "shells" (that would deal with the page formatting issues), and insert to "text" into them;
but because each shell would have a different name, the reference would have to keep changing -which seems like it will be "awkward", and probably ... problematic (?)
I could address the formatting, but there really are to many variations for it to remain clean....

[amrut]

A report throws an "enter parameter value" pop up generally when
1. there is a control on report ( including subreport controls) whose control source is set to a field from underlying table/query or a VBA function but that field/function does not exist ( deleted/misspelled)
2. The query has its criteria from a Form and that form is not open at that moment

I am confused in your case as what is happening and what do you need. Sorry friend, I give up. May be someone else be able to help you.

[markjkubicki]

I'm starting to think that I need to "rethink" my approach

the problem is:
we have a need for virtually the same report but with several (many) different "print formats" (for the most part, different versions of footers, headers, and margins) (our report fits into documents "by others", and it is important for the overall "look" of ours to match theirs....)

what I'm hoping to do is:
create a library of report "shells" (that would deal with the page formatting issues: headers, footers, <etc.> ), and insert the report "text" (the detail section) as a subreport into them;
but because each report,s shell (FixtureSchedule_Shell) would have a different name, the reference (from the subreport, FixtureSchedule_Text) would have to keep changing -which seems like it will be "awkward", and probably ... problematic (?)

Thru code, I could address the formatting is a single report, but there really are to many variations for it to remain clean....

UGH.