[AccessD] Report data changes when printing

[Ryan W]

Well I began pondering this a bit more and wondered why I wasn't using a
Snapshot.... but it turns out you cannot set the recordset type on a stored
query... and I can't use the query in the subreport directly, it gives me a
message: "Cannot use the cross tab of a non fixed column as a subquery"...



On Wed, Mar 29, 2017 at 10:51 AM, Ryan W <wrwehler at gmail.com> 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.
>
>
>
>