Unexpected Totals in Access Print Preview

[Joe Montana]

Ok, so I have a problem with the Access Report Writer. I created a
report that totals employee's hours. Your basic Rate * Hours formula.

There are some occasions where I must use a different rate, and I do
this through Detail Line Print Event code. It is not possible for me
to work this into a query.

I find that with this code, when I print or go through each page
individually it works great. When I preview the report and skip to
the last page, my totals are off. This seems to be due to the fact
that Access is not running through the code for the pages I am not
viewing.

Any ideas on how to make my final page's totals correct? Is there a
way to force Access to run through each page to get the correct totals
when the user wants to preview the report?

Any ideas would be appreciated.

Thanks!

[Keri Hardwick]

You'll need to keep track and calc your own totals instead. When you change
the amounts in the print event, you are essentially changing the "picutre"
of the number that shows on the page. Totals run on underlying recordset.
But since you're examining every record anyway, you'll be able to "roll your
own" easily.

Keri

"Joe Montana" <deck...@hotmail.com> wrote in message
news:65c8fa41.01101...@posting.google.com...

[Allen Browne]

Joe, you are correct in your assessment that the Detail_Print event
is not being triggered for the records on the pages you skip.
Consequently, you cannot reliably use that approach to solve this
problem.

Three alternatives spring to mind.

1. Perform the calcuation in the query.
I'm surprised that you say it can't be done this way: surely there
is a way to flag the conditions requiring a different rate, or to
call function that returns the appropriate rate for the conditions.

2. Base the report on a temp table.
If the data really does need to be handled programatically, the
interface that opens the report could first write the data into
a temp table, and then open the report. This approach is quite
common when #1 is not sufficient.

3. Store the data in a related table.
For the kind of application you are describing, I'm wondering
whether calculating the payments on the fly is appropriate.
Have you considered what happens to existing data if you update
your hourly rate(s) later? Storing the data would involve some
kind of batch operation that calculates the pays for the week,
permits undo for the last operation, locks down the hours once
these pays have been calcuated so old records can't be changed.
Then the report just displays the calculated results for any
batch (= week?).

--
Allen Browne (Microsoft Access MVP)
Perth, Western Australia
Tips for MS Access users at:
http://odyssey.apana.org.au/~abrowne