Has anyone else noticed this behavior?

Double clicking a form's title bar in design to maximize it takes about 3
minutes.
Saving takes at least 5 minutes.

I'm running Windows 7 Ultimate on a P4 with 2GB ram and 60GB HD with 20GB
free.
I also have Access 2003 installed.
I have tested with no other apps open, without the aero scheme, and I've
never had the RSS menu bar up.

My database is only 30MB. I've decompiled it, created a new file and
imported the objects, etc.

Does anyone know why this is happening?

Thanks.

--
Matthew Wells
matthew.wells (AT) firstbyte (DOT) net

"Matthew Wells" <matthew.wells (AT) firstbyte (DOT) net> wrote

I have seen similar behaviour on one machine running Access 2003 on win xp.
In that case the cause was found to be an old version of Symantec
anti-virus. An upgrade to the latest version fixed the problem. I'm not
saying this is definitive, but it's easy enough to temporarily disable
whatever av software you're running (if any) and see if that improves
matters..

Hope that helps.

Thanks for the tip, but it didn't help. I happen to have an old (11d)
version of SAV so I thought you hit the nail on the head. I restarted the
box and it still had the same problems. I can understand how the AV would
slow down saving, but what freezes it when maximizing a form or datrasheet?


--
Matthew Wells
matthew.wells (AT) firstbyte (DOT) net

"Stuart McCall" <smccall (AT) myunrealbox (DOT) com> wrote

I would check out a few things:

Are you talking about design mode, or just doing data entry, but no design
of the application?

Also, is this a split application, or any linked tables?

If your talking about design mode, then check for a printer that is not
attached, but is your default. (access attempts to talk to that printer, and
a network timeout can take quite a long time).

Other things can be mapped drives or linked tables to a back end mdb/accDB
that does not exist.

If you gone through the following list here:
http://www.granite.ab.ca/access/performancefaq.htm


If the basic tips like a persistent connection don't help, and other things
in the above list,
then I would be back to some type of security or scanning software.

Also, does this slow occur in all access applications you have, or just one
particular one?
(eg: local only, no network stuff etc.)

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

I've checked a few things based on the articles:

I changed my default printer to a local printer.
I checked that my AV wasn't checking network drives.
-- I am using a mapped drive --
The path is only two levels down. (no long names)
The filename is 8.3
I've never had Track Name -> AutoCorrect on

On linked tables (which I don't use much as my forms are unbound), when I
set the subdatasheet name to {None], it resets to [Auto}. I did some
googling and found a routine that actually did the job. If anyone wants it,
I'll post it.

I still have the same problems.



--
Matthew Wells
matthew.wells (AT) firstbyte (DOT) net

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

Ok, so you do have linked tables. That is a REALLY big detail

As mentioned, do you experience this problem with local applications without
any linked tables?

In other words, does this issue occur with all your applications, or only
those with linked tables?
(ones that use network resources)?

And, is there any multi-user issues here? Are these applications used by
more then one user at the same time.

Since this seems to be a split application, then I assume the front end is
on each computer.

And assuming the above, then have you tried a persistent connection?

In the front end, just open any linked table to the back end, now minimize
that table.
Now, with that table minimized, try running that form, does the delay go
away?


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

Yes and no.
There are linked tables, but I'm not using them. There is no recordsource
in any form. When I maximize a form in design view is a good example.
Either when I double click the title bar or when I use the usual max button
it takes 5 minutes.

I am on a shared drive


--
Matthew Wells
matthew.wells (AT) firstbyte (DOT) net

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

"Matthew Wells" <matthew.wells (AT) firstbyte (DOT) net> wrote

Well, that fact that you not using them still could be an issue.

For testing and to determine if this your computer or Access, or something
in your applications, it is important to eliminate these issues (even if for
testing you use a 1 form tiny application with the wizard build in less time
then it takes me to write this post).

Right, and so when you run something on a local drive without any linked
tables, do you have the same problem?

If yes:
Then the performance issue still exists, then we still on the issue of
computer + virus or some other issue.

if no:
Then obviously access CAN run fast and Access is NOT slow on your machine.
This would tell us that Access runs well and thus it not necessary you
computer or Access that is slow here. This then would hint to something due
to the setup of your application. This would also suggest we not looking to
change the configuration of access but is thus something in your application
or network setup. However, if ALL AND EVERY application no matter what runs
slow, then why bother with issues like network when no network is involved?
So it is important here to determine the above yes or no issue to guide us
on the next step here.

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

I put the file on the local c:. The SQL Server instance is on the same box,
so everything is local. I changed Access to use tabbed docs. Now when I
switch from form view to design view it takes 5 minutes. Also, no other
program is giving me any problems - only Access 2007. I've tried while
connected to the LAN and while I'm not. Same results.

Still clueless.

--
Matthew Wells
matthew.wells (AT) firstbyte (DOT) net

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

"Matthew Wells" <matthew.wells (AT) firstbyte (DOT) net> wrote

Ok, this is good. Now we eliminated the network issue.

The other question asked was does this slow down occur for all access
applications, or just the one sql one you have?

In other words, does a basic application with NO linked tables but ONLY
local accdb tables run ok on your computer?

if yes:
Then access can run great and wonderful and fast on your computer and thus
it something in the particular application.

if no:
Then access can NOT run great and wonderful for ALL applications and it has
NOTHING to do with your ONE application.


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