We help IT Professionals succeed at work.

Have criteria in report header?

treyjeff
treyjeff asked
on
234 Views
Last Modified: 2009-12-16
When we run a report it asks for two dates (start and finish), how can we have these show in the report header?
Comment
Watch Question

Commented:
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION

Commented:
Another way would be to create a form with two unbound text boxes, one for beginning date (beginningdate_txt) and one for endingdate (endingdate_txt).  Then in the criteria section of the your query for the date on which you are running your report, enter "between forms!yourform!beginningdate_txt and forms!yourform!endingdate_txt" (without the quotes).

When running the report, you can set yourform.visible = false, and add the fields into your report the same way as in the criteria in the query (forms!yourform!beginningdate_txt and forms!yourform!endingdate_txt)

Commented:
A third option...
I have grown *very* fond of putting report parameters into a local work table.  Then I tie the table into the query used by the report.  Voila!  No more Forms!Formname!FieldName...
Can also run reports *without* having the form open.
Here's a work table, tblOptions, for your specific situation (e.g. from/to date parameters):
bytWork is a byte field with:
  default value 0 (zero),
  validation rule"=0",
  Required=Yes,
  Indexed=Yes (No Duplicates)
datFrom is a date field
datTo is a date field

bytWork is only in the table to make sure that only one record ever gets put into the table.

Go into the query that your report is based on and add tblOptions to it.  Do not link this table to any other table in the query.  Add the fields [datFrom] and [datTo] to the query grid.  On the criteria row for the date field used by your report, type:
  Between [datFrom] And [datTo]

In your report, [datFrom] and [datTo] will now be available as normal fields that you can drop in the report header.

Side note: If your query happens to already have multiple tables and any of them are joined with arrows (Left outer join, etc.) then you will get an error when you run this.  To solve that problem, don't put tblOptions in the query.  Instead, define a NEW query which contains tblOptions and the original query.  Drag all the fields to the grid from your original query and tblOptions.  Add the "Between" criteria as described above.  To get these dates to show up in your report header, put them all by themselves in a subReport based solely on tblOptions.

Now for the user interface which runs the report... Bind the form to tblOptions and drop the fields on the form.  Add a buton to open the report.  In the code behind the button, *before* you run the report, DoCmd.RunCommand acCmdSaveRecord.  That will force access to save the dates to tblOptions before the report runs.

<Whew.>  I think I covered everything.  If not, I'm sure I'll hear about it! (lol)  This may sound like a bit of work, but it really ain't that bad.  It makes overall application design a lot easier!  You won's miss those "Forms!Formname!FieldName..." expressions a bit, I promise!!

Author

Commented:
Well in our query we have it set under query to ask for start date and finish date :)  I just want the easiest way :)

Commented:
treyjeff,
I'm all for easy, too, but I'm also for nice-to-the-user.  (I'm not trying to be mean to you, I promise!)
Another cool side-effect is that the criteria the user enters are saved.  Next time the report prompt opens, they can see the values they used last time.

Commented:
A couple more general comments about using this method...

First off, this method is *not* well-suited to a front-end that is run by multiple users.  By that I mean if several people have shortcuts to the (front-end) database running on a network.  Each user's change to the report parameters can affect the other users.  If you install a separate font-end on each user's machine then you will have no problem.

Next, if you are doing a different kind of parameter this gets even easier.  Let's use "Customer" as an example...  If you have a table of customers (tblCustomers), add the customer field, lngCustomerID, to tblOptions and make it a combo box on the report prompt form (assuming that you have a customer lookup table, of course).  Now when you add tblOptions to the report's query, link [tblOptions].[lngCustomerID] to [tblCustomers].[cntCustomerID].  The query is now customer-specific... no query criteria!  Only records where [tblOptions].[lngCustomerID] match [tblCustomers].[cntCustomerID] will be included in the recordset.

That's all I can think of for now...

Author

Commented:
It worked :)
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.