Running slow in design mode

[Keith1951]

While I love Access and have done for more than twenty years, I have for perhaps the last 5 years been troubled by it going slow when going into design mode, sometimes slow to the point of being unusable

Strange thing is that the problem will usually clear itself within a few weeks and everything return to normal.

There are plenty of people complaining about the issue on the web and the odd bit of advice, now of which has worked permanently.

If any kind soul could put me out of my misery then that would be hugely appreciated. I have attached a X+Zipped Powerpoint file that illustrates the issue better than I can describe it. Sometimes it is even worse than what you see here.

Many thanks for listening! ..... Keith

 

[JHB]

Is it only one database or more?
If only one, have you tried a "Compact and Repair" or compiled/decompiled the database or imported all into a new database?
What if you open an empty table?

You do not write what you've tried, could you do that?

 

[Keith1951]

Thanks JHB,

It happens with any database on the affected machine

When things get truly deperate and urgent I copy the database to a USB drive and run with no problem on my wife's machine

Have tried repair and compact - many times

Adding new table sees it similarly afflicted

Have reinstalled Office 365 - many times

A sad tale .... K

PS none of my databases are split front end/back end

 

[Mark_]

Task manage is your friend. When your machine starts running slow, open it and view the processes running. Look for those that should not be, those that are using an excessive amount of memory, and those that are using a lot of CPU time.

These often "Clear up" when either the naughty process finally is no longer starting or when you receive an update that clears it up.

From your description "run with no problem on my wife's machine" my first step would be to identify what is different on your machine.

 

[JHB]

Mark_ offer a god advice.

..
When things get truly deperate and urgent I copy the database to a USB drive and run with no problem on my wife's machine

What happen when you copy it back to your computer, still slow?
Do your wife have installed Office 365?

..
Have reinstalled Office 365 - many times

The problem by reinstalled is, even if you do an uninstall, you can't be sure all "shits" goes away so you can start a clean install.
Have you tried to compiled/decompiled the database and also imported all into a new database?
Here is a link how to decompile.
http://www.fmsinc.com/microsoftaccess/performance/decompile.asp

Is you wife's and your computer the same type? Laptop/desktop computer.
Have you tried to stop virus software from running, only for testing suppose?
You write that you have had problem the last 5 years, is it on the same computer?

 

[Pat Hartman]

Make sure your default printer is connected to your PC or available via WiFi. Access relies on the printer driver when in design view to provide formatting information.

Compare your Access and Windows versions with that of your wife. Is she on the same update schedule as you are?

 

[CJ_London]

another thought. Is your desktop cluttered with many and/or large files? If so, try moving them off the desktop. I had a similar problem on XP many years ago, clearing the desktop solved the problem. I think it is something to do with memory management.

 

[The_Doc_Man]

When things get truly deperate and urgent I copy the database to a USB drive and run with no problem on my wife's machine

If the problem changes when you move it to another directory-enabled device (and USB IS a directory-enabled device), the problem that you left behind is often lock contention. The lock database for Windows is like a "tree" structure with the root device as the root of the tree.

It happens with any database on the affected machine

This further bolsters the theory that it is lock contention.

You can check on file handles using Resource Monitor. Launch the monitor and select the CPU tab. There are four headers, the third of which is "Associated Handles". Put an asterisk in the "Search Handles" selector at the right of the header bar. The list should fill in beneath the header. Now in that section, click on the column header "Handle Name" and it will alphabetize that column. Use the scroll bar to see if a particular file in the list is familiar to you. Each "handle" in that list is an open file. Note that a "Type" of "Section" refers to a memory area that is treated as a loadable memory section, having to do with the "section source" for "pure code" sections. You, on the other hand, are looking for a "File" under the "Type" column.

OK, the above is a long shot - but if you see lots of handles on one of your app files, you can track it down and see who is trying to get to the file. The PID column is the process ID and corresponds to the PID in the "Processes" section of that same tab. You will do best to click in the PID column of Processes so you can rapidly correlate the processes that are trying to get in to your file.

To see WHO each process represents, once you know the PID info, you can swap to the Disk tab, for which the 2nd header is Disk Activity. The PID there matches the PID on the CPU tab. There, you will see the file name AND the username.

 

[Keith1951]

Many thanks to all for that amazing reaction.

I will spend a day or two working through all the ideas, I still have hope

Will let you know how I get on ..... best, Keith

 

[Keith1951]

Slow again when returned to my laptop whether run off the USB or copied back to the hard disk ...

Wife runs Office 365 - off my account, cheap skate

 

[Keith1951]

another thought. Is your desktop cluttered with many and/or large files? If so, try moving them off the desktop. I had a similar problem on XP many years ago, clearing the desktop solved the problem. I think it is something to do with memory management.

Thanks CJ ..... indeed usually pretty full desktop - will test when the problem comes back - everything went back to normal yesterday

 

[Keith1951]

All, truly grateful for all the responses, unfortunately (not) the problem cleared itself yesterday after only a week this time ....

Trying some of the things suggested will therefore have to await the problems return :-(

Many thanks, Keith

 

[MarkK]

In some cases I've seen these settings make a dramatic difference...

    DBEngine.SetOption dbMaxLocksPerFile, 1000000
    DBEngine.SetOption dbMaxBufferSize, 500000

...and I routinely just run this code on startup.
Mark

 

[Keith1951]

In some cases I've seen these settings make a dramatic difference...

    DBEngine.SetOption dbMaxLocksPerFile, 1000000
    DBEngine.SetOption dbMaxBufferSize, 500000

...and I routinely just run this code on startup.
Mark

Many thanks Mark

I am a user rather than technical

Looks like a registry item ... is this where I apply the settings?

Cheers, Keith

 

[CJ_London]

Looks like a registry item ... is this where I apply the settings?

No. In vba code in the open event of the first form to be opened when the db opens

 

[Keith1951]

ah, ok ... makes sense, many thanks, Keith

 

[Keith1951]

have put this into all the databases I use without complaint

Now fingers crossed