On Wed, 08 Jun 2005 22:41:23 -0230, Tim Marshall
<TI****@PurplePandaChasers.Moertherium> wrote:
Chuck Van Den Corput wrote:
In one of my apps, I developed a calendar report composed of a 6x7
grid of subreports, one for each potential day in a month (the worst
case scenario is that a month spans 6 weeks, like July 2005).
The report logic works fine and the report can be printed when the
front-end and back-end both reside on my hard drive. In a live
environment however, when the back-end resides on a network drive, the
report doesn't get printed. It *appears* to spool to the printer but
never reaches the printer nor results in any sort of error message.
Does anyone have any idea which system resources are at the root of my
problems? What do I not have enough of? (Easy now!)
Or perhaps there is a less CPU-intensive way to generate a calendar?
I think that depends. 8)
You have 42 sub-reports - do you have a routine that makes each grid
visible/invisible (you'd only need this for the sub reports on the first
line and last two lines of the "grid")? Does this or another routine
assign a date value to each subreport? That's how I'd do it (it's how I
run a little mini date picker calendar that doesn't rely on any 3rd
party calendar controls) and I don't see that creating a problem in the
environment you describe.
Tim, I am probably implementing my calendar similarly to what you have
described. 42 sub-reports all drawing on a prepopulated temporary
table with daily events with a "day number key" from 1 to 42.
As I mentioned, generating the report, even in a network environment,
is not the problem. The problem comes when the users attempt to print
that report. Presumably Access goes through its report generation
logic one more time, as is its wont, but somehow the resultant report
never quite reaches the printer. And that's where I am lost. Where in
the path from Access to the printer does this transmission die?
Chuck
