[AccessD] Report data changes when printing

[John Colby]

Can you close the report / reopen it before printing?

On 3/29/2017 11:51 AM, Ryan W wrote:
> An interesting little thing I caught the other day...  we never experienced
> this before because we always used overlapping window interfaces and it
> made it harder to 'multitask' that way.
>
> I have a form that builds two temp tables based on some criteria you feed
> it. Then the user selects 4 targets to report from the list.
>
>
> The report has 4 dynamic fields that get their caption on the Report_Open
> event because the data is pivoted across 4 data points and as far as I know
> the only way to make the dynamically named column headers is to loop
> through the a recordset and set the "Caption" property each of the 4 text
> boxes at that time.
>
> When you hit the print report button the report comes up in print preview
> mode. Ok everything is good at that point.
>
> But....
>
> If the user goes back to the FORM tab and unchecks the 4 selected options
> (which make the 4 textbox captions) and selects 4 DIFFERENT ones and
> presses the "print" button again, from a VISUAL standpoint nothing has
> changed.. it just simply re-focuses the report that was left open.
>
> Until..... the user prints it.  Then the pivot/transform data has changed
> but the header has not because that was done on Report_Open time.
>
> So, I guess really my question or remark is:
>
> Why does MS Access "Requery" the report recordset when printing, and not
> simply print what is on screen?
>
>
> I've already come up with a number of fixes for this:
>
> 1) If the report loses focus, close it.
> 2) If somehow that doesn't work, next time the user presses the print
> button if the report .IsLoaded, close it.
>
>
> So all of this brings up an interesting point that I assume could also
> cause grief. If for some reason one user had a report up but neglected to
> print it and another user changed some of the data that the report is using
> BEFORE the original user hit print it may change the report data. However
> unlikely that is.

-- 
John W. Colby