long-time report fails intermittently under Access 2007 SP2

[Gary]

A report that I've been runnning successfully for many years (first in
Acdess 97 and later in Access 2007 SP1) is now causing trouble. I've
recently installed SP2 (on XP SP3.)

It's a bit baffling. If I use OpenReport . .. acPreview . . . and
then execute print from the printer window, it prints perfectly. But,
when using OpenReport . . acNormal (as I have always done and must do
in my production environment), only about half of the report is
printed on the page. About half way down the page, the report is
blank. And it is happening only when printing certain content.

I thought it might be a timing issue, so I added a counter before and
after OpenReport - but that did not help. It's only happening on this
one report. Other similar reports running in the same code are fine as
always.

Has anyone seen behavior like this before?

 

[Tony Toews]

And it is happening only when printing certain content.

What kind of certain comment? What happens if you try printing to a
PDF printer or a different printer?

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[Gary]

What kind of certain comment?  What happens if you try printing to a
PDF printer or a different printer?

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages -http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
  updated seehttp://www.autofeupdater.com/

Tony - Thanks for the reply. The report contains summary town data
such as parcel counts and various average property values and
multipliers. The error seems to occur only on larger towns - towns
that have more parcels and more value. So, overflow would be a suspect
- but I don't see how that could be an issue since A) in past years
the report has been running successfully for all towns, and B) parcel
counts and values have actually decreased again this year.

If it were related to data type or overflow, can you imagine why the
report would populate correctly from Preview, but not if sent directly
to the printer?

As soon as I can set up, I'll try your suggestion to send the report
to another printer.

 

[Tony Toews]

Tony - Thanks for the reply. The report contains summary town data
such as parcel counts and various average property values and
multipliers. The error seems to occur only on larger towns - towns
that have more parcels and more value. So, overflow would be a suspect
- but I don't see how that could be an issue since A) in past years
the report has been running successfully for all towns, and B) parcel
counts and values have actually decreased again this year.

If it were related to data type or overflow, can you imagine why the
report would populate correctly from Preview, but not if sent directly
to the printer?

No, I have no idea why this would be happening. Sounds like ordinary
data.

As soon as I can set up, I'll try your suggestion to send the report
to another printer.

Try installing a PDF printer such as CutePDF and see what happens
then.

Also is this happening on only one PC or multiple?

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[Gary]

No, I have no idea why this would be happening.  Sounds like ordinary
data.  


Try installing a PDF printer such as CutePDF and see what happens
then.

Also is this happening on only one PC or multiple?

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages -http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
  updated seehttp://www.autofeupdater.com/

After a lot of additional testing, I've decided that the problem must
be related to printer cache issues. The reports are now running on a
newer, faster printer - and it seems that perhaps the cache isn't
being cleared fast enough from the previous report where that previous
report contains one of our larger data sets. My old reliable report is
being stepped on - somehow - it seems.

To get at the issue, I've inserted a new "this page intentionally
blank" report in between the two where the data set is particularly
large. And we do mean i-n-t-e-n-t-i-o-n-a-l !

Thanks much for your help.

 

[Marshall Barton]

After a lot of additional testing, I've decided that the problem must
be related to printer cache issues. The reports are now running on a
newer, faster printer - and it seems that perhaps the cache isn't
being cleared fast enough from the previous report where that previous
report contains one of our larger data sets. My old reliable report is
being stepped on - somehow - it seems.

To get at the issue, I've inserted a new "this page intentionally
blank" report in between the two where the data set is particularly
large. And we do mean i-n-t-e-n-t-i-o-n-a-l !

That kind of thing will happen if you are printing the SAME
report multiple times with a different filter/where
condition/record source. In this kind of situation, usually
in a code loop, it is safer to use a delay loop until the
report finshes before opening it again:

For Each something In somecollection
stCriteria = "whatever = " & something
DoCmd.OpenReport "my report",acNormal,,stCtiteria
'wait for report to close
Do While CurrentProject.AllReports![my report].IsLoaded
DoEvents
Loop
'go on to report for next something
Next something

If that's the kind of thing you are doing and you never had
the problem before, I'll take a guess that your old printer
was being spooled very quickly, but the new one is not.

 

[Tony Toews]

After a lot of additional testing, I've decided that the problem must
be related to printer cache issues. The reports are now running on a
newer, faster printer - and it seems that perhaps the cache isn't
being cleared fast enough from the previous report where that previous
report contains one of our larger data sets. My old reliable report is
being stepped on - somehow - it seems.

To get at the issue, I've inserted a new "this page intentionally
blank" report in between the two where the data set is particularly
large. And we do mean i-n-t-e-n-t-i-o-n-a-l !

Thanks much for your help.

Yowzer, that's a new one to me. Possibly a DoEvents between the two
reports might help as well.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/