Pulling static text box contents from table into report header

[Hardrock]

I am using a form to populate a table (tblcoverpage) with a single record which will hold static information that will be used in a cover page for a report. The information includes "committee name, filer number, chairperson name, chairperson address, year, etc. This information will be entered once and only infrequently changed.

Some of this information will be used to fill in repetitive header information on every page of the report.

I have created textboxes in the report where I need to reproduce this static information over and over

I thought I could just use =tblcoverpage.committeename in the text box where I want the Committee name to appear but I get the error #Name? instead of the contents of the Committeename field in tblcoverpage. I have cleaned up my explanation for the sake of clarity and will confess that "committeename" is actually Committee Name. Could the space cause this problem?

[June7]

Yes, spaces can cause a problem. Advise not to use spaces and special characters/punctuation (underscore is exception) in naming convention.

Cannot refer to table directly like that.

If the information is in a table then include the table in the report's RecordSource.

[Hardrock]

Report is getting data from multiple tables. Not sure how to add multiple tables in recordsource

[June7]

Don't understand. If the report RecordSource already has multiple tables, should know how to add another.

[Hardrock]

My explanation was incorrect.....Report gets data from a query that pulls data from two.....now three tables. This seems inefficient since I'm adding almost all fields from three tables to be able to get them into the report. Is this the only/best way to do this? Seems that one SHOULD be able to get report field directly from the table rather than having to create a query.

Another problem is that the tblcoverpage (which has all the organizational info to use in both the report cover page AND report headers on each page) has contact info on the chairperson and treasurer and I didn't anticipate that using fields like "address", "city" etc would cause problems because I figured that I would be defining the table from which those fields would be coming whenever I needed to reference them on the cover page and in the headers. Now, I'm renaming all fields so there are no duplicates across tables.

I don't think I want to just add the chairperson and treasurer in the tblcontacts because of the fact that on cover page and in headers, I only want those two people to show up...make sense? Is there a better way to store this "static" organizational information. As indicated above, I'm using a form to enter organizational info and storing it in tblcoverpage.

[June7]

Could do a DLookup() expression in textbox but domain aggregates can be slow performers.

A table is best if you want the 'static' org info easily edited and easily available. Otherwise, have to build into report design as labels.

[Hardrock]

OK, I used a table and got this! Thanks.

The tblcoverpage has beginning and ending date fields that I'm entering with the form mentioned above but I just realized that I'm reporting contributions based on dates entered when a parameter query runs. It would be best to be able to have the beginning and ending dates entered through the parameter query to show up in the report header....otherwise the contribution details (which are correct) may not sync with the report beginning and ending dates that were entered on the form. In short, I think all the report details as far as contributions will be right but it's not very intuitive that users are entering dates on which to base the report but they may not see those dates in the report header. I would have to provide instructions reminding them that to have the dates match up, they will have to edit the form each time they run the report. The report will only be run twice a year on mandated reporting dates so this is not a huge stumbling block (that is, users should recognize the issue with the dates) but if this could be eliminated, it would be best.

[June7]

You are using parameter input popups in query? I NEVER do that. I avoid any dynamic parameters in queries. I send filter criteria to form or report when opening. I reference controls on form for input.

[Hardrock]

Yes, you mentioned that in an earlier reply but I had already started down this path and was very close so I decided just to finish it with parameter query and then go back later and try your way. Obviously, I don't really know what I'm doing and I'm not sure I understand your method. I guess to run this report, you would open a form which would ask for beginning and ending dates. I further presume that that form "stores" those dates and calls the report which looks back on the form to see what dates to use? Am I close? How is this better?

Update: I just read Allen Brown's reasons for avoiding my method and then remembered that you were worried that there's no way to validate the input.

Got this off Brown's site:
His reasons -----my response......
Inflexible: both dates must be entered. -----No way to avoid this since the state mandated report does ALWAYS have beginning and ending dates that are SPECIFIED by the state.
Inferior interface: two separate dialog boxes pop up ----I actually think this is an advantage in that it's step by step
No way to supply defaults. -----There can be no defaults unless I provide the whole database to the end user before each reporting period and I don't want to do that.
No way to validate the dates.----This is the only argument I can't rebut; however, I think this is not a major hurdle.

[Hardrock]

All that said, I'm back to the original question....can the dates entered for the parameter query be filled in on the report? If yes, how best to do that?

[June7]

A default could be the current date or maybe the maximum or minimum date in the table.

Yes, prompting has its advantage in that user can't bypass it. However, if user makes invalid entry, the query will still run and report will open, with wrong results and user gets frustrated.

You can create a field in query that uses the same prompt as the criteria:

SELECT *, [enter date] As DateFilter FROM tablename WHERE [datefield] = [enter date];

Now bind a textbox to the constructed field.