Hello Accessarians,

I've have had constant hell-slow performance in design view for a long
time in Access 2007 with Vista x64. I'm talking about 5 seconds to
select a control...... 5 seconds delay to adjust the size of a text-
box etc. Basically hellish, and despite being an access lover for 10
years, I was actively looking for an alternative product as I was so
disgruntled with the MS OS + MS Database performing like a dog.

What brought my frustrations out, was I had a HDD failure, and
reloaded Vista + MS Office onto a new machine, and a virgin setup like
this was still acting so poorly. (Q9550/8Gb/Vista x64)

OK, so searching about wasting hours (I've already probably wasted 50+
hours looking for the slowness cause..... I read Tony's Performance
FAQ all the time!) - and someone in a post mentioned to close the
service SPOOLSV.EXE

Yes..... It solved the slow issue!!!!!!

I only had the 1 single printer installed, a Network printer on a D-
Link print server. I have the same slowness issue at work as well,
and there is perhaps 5 or 6 HP Network printers installed. (not a D-
Link Print server though).
I am obviously excited to go in on Monday and try disabling the
printer spooler.

There is a sea of people with Slowness in Access Design mode.
Thousands and thousands, I can see by the huge number of complaints
etc. I hope SP2 of Office fixes this. It's not really acceptable to
slow the print spooler.
I'm very disappointed in the time wastage inflicted on the whole
access community with issues like this. So many oddball performance
adjustments.


Any comments on the SPOOLSV.EXE rendering MS-Access unusable in Design
Mode?


Thanks everyone,


Elias Farah.

"elias" <elias.farah (AT) scw (DOT) com.au> wrote

I think in just about every other performance post question here that I
answer, I see after checking Tony's list, I see the next thing I suggest is
to check if you have any network printers installed.

The solution here is not to blow out your printer spooler. While killing the
printer spooler might fix the problem, that's kinda like cutting a person's
leg off because they have sore toe. Perhaps we needed just put some shoes on
the person's feet and not cut their legs off?

The solution is to make sure that you have a printer installed that is local
to your computer *and* set as your default. When an access report (or form)
loads, then network chatter occues. In fact, even word and Excel will
attempt to load or ascertain information about the default printer.

I have ALWAYS installed an local printer to my computer during access
development. In fact, I use an pdf printer so as to limit the fact that I
may not have a real physical printer installed (this is especially so the
case when working on my laptop). so, I have NEVER EVER developed using an
active network printer as the default in access. This doesn't just apply to
access, but anything else you going to be developing with that uses a
printer and that may be requesting printer layout information during the
development process.

As mentioned, I think Killing or destroying or stopping the printer spooler
is a little bit draconian here.

Instead of disabling the printer spooler, try setting up a local NON network
printer and set that as your default. In fact I find it really handy to have
a pdf a printer installed during development since then this not only solves
the problem of advoding a "slow" network printer, but it also saves you a
ton of paper when you want to look at the results of a report you are
printing/testing.

Here is one great pdf maker/printer driver.
It is absolutely Free,
And free means no watermarks, no nag screens, no annoying Popup
advertisements, no time limits etc.

It is also very fast, and works very well. I highly recommend it.
http://www.acrosoftware.com/products...df/Printer.asp

It's not "really" the print spooler that slowing this down. It's the fact
that you have a network printer that's not connected to your computer or the
connection to the network printer is slow and that printer is set as the
default (or worse that printer is not even available).

As I said, try setting up a printer that's local to your computer, and as
your **default**.

I've never even considred to develop anything that has forms and reports
when connected to an attached printer that not local. Forms and reports can
be printed in access, so once again printer information is needed for that
form load, and especially the form save.

Well, I dont think this is so much the spooler running as is the issue of
not having a printer attached and available during the access development
process. So, keep in mind those access forms and report need information
about the printer layout. If access cannot get that informaton...then you
have a real bottle neck.

Tony's performance FAQ really pertains more to the running process, not that
of the development process. At any rate, perahps a better distinguishing
between running, or developing needs to be make here.

Having said all the above, I am **always** very much indebted and appreciate
you coming back here to explain your problem and what worked for you. This
helps the community VERY much. and so regardless of people like me never
having been bitten with this problem, it's still very much appreciated that
people like you come back here and spend time to explain their problem and
their eventual solution. I sincerely wish more people did what you do, as
all the community here would benefit enormously. So, thank you very much.

When access 2000 came out, we started receiving reports of people having
problems on a network. As the community discussed the issue we found out the
soltion was to use a persistent connection. Nine out of ten times this
solved this performance problem. And in fact after some amount of time, we
also found that this issue was not limited to a2000, but in fact access 97
also suffered from this network problem.

I've not seen anything in SP2 that will likely solve your above problem, but
then again this problem of the issue of having a printer that's not attached
a computer during the development process is pointed out quite often in the
newsgroups here...at least it is by me....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com

i've never even thought of using a PDF writer as the default printer when
i'm developing - what a great idea! you always seem to cut through the murk
and come up with the simple solutions, Albert - time-saving, money-saving,
simple to implement. and so obvious, some of them, AFTER you point them out,
that i'm shaking my head, saying "why in the world didn't i think of that?"
thanks so much for all the help you give the rest of us here in the ngs.
tina

ps. i use CutePDF, too - cool little program. found the link here in the
ngs - where else? - and probably from one of your posts! <g>


"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote

elias <elias.farah (AT) scw (DOT) com.au> wrote:

Thanks muchly for posting.

That said Albert's suggestion of creating a local printer, even if a PDF printer, is
a better solution.

Please post back if this works.

Thanks, Tony

P.S. I'll be adding this suggestion to the performance FAQ.
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/