Report print preview hanging (sometimes)

[KD]

Situation:
---------
I've written a database that works fine on some PCs, but
not on others. In particular there is a report that locks
when print previewing.


Questions:
----------
- I'm interested in what settings I should be comparing
between the working and non-working environments.

- What hardware/memory allocation is recommended for
Office 2000? (Although the operating system is newer than
that of the developed PC, the hardware is not).


Database:
---------
The query behind the report joins 8 tables.
- I've checked that locking is at record level.
- I've analysed performance on the report, and made the
recommended corrections (introducing an index and
adding "Option Explicit" to the beginning of the VB for
each report object).


Environment:

 

['69 Camaro]

Hi.

In particular there is a report that locks
when print previewing.

Is there a valid default printer set up for each user's profile on the
Windows 2K computer? In other words, when the user opens another Microsoft
Office application such as Word and tries to print a document, does the
document print automatically without the user having to go through print
setup to configure it first?

- What hardware/memory allocation is recommended for
Office 2000?

Minimum hardware recommendations made for Office 2000 are based upon common
computer configurations of five years ago, not today's standards. Can the
computer handle at least 256 MB of RAM? More would be better. Is the CPU
at least 1 GHz? Faster would be better. Much faster would be much better.

The query behind the report joins 8 tables.

That's a lot of joins for a Jet query. One should expect performance to be
noticeably slower at four table joins, and increasingly slower as more joins
are added. Proper indexing can help performance considerably.

Make sure that all computers have the latest versions of the service packs,
Office 2K SP-3 and Jet 4.0 SP-8. If the report has a text box calculating
the page number and number of pages (for example, "Page 1 of 247 Pages"),
then remove the calculation for the number of pages, because Access must
format _all_ pages in the report before this number can be calculated,
thereby slowing down the report.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[Chris Mills]

-PC's can just lock-up, esp. after much use. When I strike that, I just
reboot. No-one has told me any better.

-Allocations, even where available, might affect performance but not
"locking-up", I would think. I had a customer who said my app locked up.
"How long did you leave it?"
"10 minutes perhaps"
"Leave it for an hour or two, go out to lunch or something"
"You must be kidding, right?"
"I'm not saying that's normal. I'm saying do it for me as a test"

-Joining 8 tables I would regard as getting complex (though not that you
shouldn't be able to, a query reporting "too complex" I regard as the limit).
But there's a high chance, in that many tables, of having difficulty working
out efficient indexes. None of us besides MS really knows in detail how Access
or Jet optimises queries.

-Access2000 is known to be relatively unstable, esp on databases more than
about 30mB. Making sure it's patched to at least SP-1, might help.

-Access2002 is reported to be much more stable. Though I have A2002, I don't
have any statistics to prove this one way or another.

-If it works fine on some PC's but not others, what's the difference? I'm
sorry to say that only you can tell us that.

Regards and sympathies
Chris

 

[KD]

Gunny & Chris,

Thanks for suggestions - I'll see how I go.



The circumstance is a little unusual in that I don't have
direct access to the PC where the problem occurs.

I'm making changes to a database on behalf of someone else
for their client - they tested and were happy, installed,
then come back to me asking "what could be wrong?". Hence
the equivalent vagueness in my posting - and hoping to
identify a list of "most likely suspects" to compare
between PCs.


KD

 

['69 Camaro]

Thanks for the update. Good luck.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[Chris Mills]

The circumstance is a little unusual in that I don't have

direct access to the PC where the problem occurs.

That's not unusual. But it sure makes diagnosis a problem, even if you have a
terminal emulator.

They could have a corrupt PC, a corrupted database without it actually bombing
out, too many records taking longer than expected, a bad printer driver,
missing References slowing stuff up if it does not bomb out, it can be very
hard to say. I just live on hope -I have enough sites to know my app itself
works fine, so must be them ;-) ;-)

If it's only one report or just part of the program, then that could eliminate
a lot of things?

Chris