Slow DB (1 Viewer)

Pat Hartman

Super Moderator
Staff member
Local time
Today, 02:19
Joined
Feb 19, 2002
Messages
42,981
I am confused by your response.
Normal operation:
-- All users must have their own personal copy of the FE on their LOCAL hard drive and the tables are linked to the BE on a LAN drive
Test operation
-- You imported the linked tables into the FE and you tested it
---- on your local PC
---- on the server

It is important to be clear because depending on which situations were fast and which were not, highlights the problem. If the first and third are slow but the second is fast, the problem is with the LAN. If the second is slow also, then the problem is with the application. You really need to isolate the scope of the problem so you know what you need to address.

One comment you made brings up an issue I had at one time. You said the app was very slow when going from design view to form view. When I experienced this, it was caused by me working on my company laptop when NOT connected to the LAN. That disconnected my default printer. Once I defined a different default printer, that slowness went away. I don't know if that is the main problem but it is also something to investigate. Make sure that everyone has a default printer defined for Office and that the printer is connected.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 02:19
Joined
Feb 19, 2002
Messages
42,981
I'll just go away now.
 

Gismo

Registered User.
Local time
Today, 08:19
Joined
Jun 12, 2017
Messages
1,298
I am confused by your response.
Normal operation:
-- All users must have their own personal copy of the FE on their LOCAL hard drive and the tables are linked to the BE on a LAN drive
Test operation
-- You imported the linked tables into the FE and you tested it
---- on your local PC
---- on the server

It is important to be clear because depending on which situations were fast and which were not, highlights the problem. If the first and third are slow but the second is fast, the problem is with the LAN. If the second is slow also, then the problem is with the application. You really need to isolate the scope of the problem so you know what you need to address.

One comment you made brings up an issue I had at one time. You said the app was very slow when going from design view to form view. When I experienced this, it was caused by me working on my company laptop when NOT connected to the LAN. That disconnected my default printer. Once I defined a different default printer, that slowness went away. I don't know if that is the main problem but it is also something to investigate. Make sure that everyone has a default printer defined for Office and that the printer is connected.
Sorry, missed this post.

just confirmed with IT, ever remote desktop is automatically configured with a printer at time of user created
I have a printer configured, still slow between forms and from design view to form view
i dont have an issue with data selection, or running queries with large amounts of record,
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 02:19
Joined
Feb 19, 2002
Messages
42,981
You still didn't confirm the results of your test. Is the app fast when the tables are embedded and the database is LOCAL.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 06:19
Joined
Feb 19, 2013
Messages
16,553
I have a printer configured,

think you are missing the point. Pat is saying that the slowness was being caused by the default (configured) printer not actually being connected because she was working offline. So is your printer online to you at the moment i.e. local to you
 

Minty

AWF VIP
Local time
Today, 06:19
Joined
Jul 26, 2013
Messages
10,355
Just to back the printer issue up, I have been setting up some specialised labelling for a client, using a specific label printer.
When I haven't had it connected, opening the forms in design view got painfully slow, and it took me a while to work out why.

Also if your forms have complex queries as their rowsources, access will often run those queries or at least check they are valid before opening the form design view.

Finally, if this all happened very randomly without you making any noticeable changes, and even a backup that used to be okay is no painfully slow, then I would suggest you have some form of network problem.
Possibly a network "storm" caused by a random new device causing an IP conflict or something similar.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 01:19
Joined
Feb 28, 2001
Messages
27,001
Reading the thread from Social.Technet (post 25), this seems to be a widespread problem yet I have not seen it on Ac2010. You say you have been developing this DB and these forms for a while. Is there any chance that at least one of the forms has a VERY large number of controls on it? (That includes things on a TAB control.) Or, if not now, has it had over 700 controls on it non-simultaneously - as in "deleted a control, replaced it or converted it to something else"?

I'm going to suggest an experiment that might be tricky, but it might also pinpoint something. When you have this REALLY slow form opening (the ones that take over 30 seconds), set up this situation.

Using your Remote Desktop setup, prepare to do testing for the case where the FE being run is physically on the same machine as its BE file.

Start Task Manager and switch to the "Processes" display. Normalize the window so that you can see some of your desktop.

Open your database. Normalize the window (if possible) so that you can see TM and your DB at the same time on your desktop.

Now launch one of the "ugly" forms. (Note: To figure out all of this, you might have to do this more than once.)

Immediately use the Task Manager as follows: Click in the CPU, Disk, and Network columns to identify the highest users of those resources. Also click the Memory, though I'm not betting on that one being an issue. Since your FE and BE are on the same machine, your Network load should be fairly low.

Switch Task Manager to "Performance" and look for peak usage in each of those categories. You want to identify whether you have tripped over a bottleneck somewhere. TM will show you broad-brush ideas of where you are eating resources.

From your Windows "Start" button (lower left corner), Click, scroll to Windows Adminstrative Tools, expand that, and start Resource Manager.
Again, while trying to load one of your stubborn forms, start it and switch to RM. In the menu, you can focus on CPU, Disk, Network, Memory, or the Overview screen. You want to see which files your task is hitting and how hard.

I'm trying to find out whether, when this craziness hits, you are disk-bound, network-bound, or CPU-bound. In a "normal" profile I would expect a brief burst of disk activity that might be too quick to see in detail (though Task manager's performance page DOES keep a history of the past several seconds). Then you would have a burst of network activity alternating with or parallel to CPU activity. Resource Monitor might tell you that the "network socket" you are using goes through the Loopback connection because the BE is on the same machine with the FE.

In a well-behaved system, those CPU and Network bursts would also be short-lived. In your case they might not be. It would also be interesting to know whether the CPU hog was MSACCESS itself or the ACE engine in a separate thread. In a brief load, you might not be able to see that, but for something running very long, RM might call it out separately. The trick here is to figure out what is working hardest.
 

Gismo

Registered User.
Local time
Today, 08:19
Joined
Jun 12, 2017
Messages
1,298
think you are missing the point. Pat is saying that the slowness was being caused by the default (configured) printer not actually being connected because she was working offline. So is your printer online to you at the moment i.e. local to you
Hi, yes I understood, the printer is connected and local
when we connect to the remote desktop it is connected as well
 

Gismo

Registered User.
Local time
Today, 08:19
Joined
Jun 12, 2017
Messages
1,298
Just to back the printer issue up, I have been setting up some specialised labelling for a client, using a specific label printer.
When I haven't had it connected, opening the forms in design view got painfully slow, and it took me a while to work out why.

Also if your forms have complex queries as their rowsources, access will often run those queries or at least check they are valid before opening the form design view.

Finally, if this all happened very randomly without you making any noticeable changes, and even a backup that used to be okay is no painfully slow, then I would suggest you have some form of network problem.
Possibly a network "storm" caused by a random new device causing an IP conflict or something similar.
not all my forms have complex queries or multiple sub forms
also, it is not just my DB that is slow, when i work on the remote desktop, which has a copy of the file, it is just as slow
i have one form which has no source, (call it a menu form) from design to form view is slow as well so i dont think it is a network issue
when i use a drop down box, the data is available immediately, local or from remote desktop, i doubt it could be a network issue, but, anything is possible

i have also played around with the cache settings, no improvement
 

Gismo

Registered User.
Local time
Today, 08:19
Joined
Jun 12, 2017
Messages
1,298
Reading the thread from Social.Technet (post 25), this seems to be a widespread problem yet I have not seen it on Ac2010. You say you have been developing this DB and these forms for a while. Is there any chance that at least one of the forms has a VERY large number of controls on it? (That includes things on a TAB control.) Or, if not now, has it had over 700 controls on it non-simultaneously - as in "deleted a control, replaced it or converted it to something else"?

I'm going to suggest an experiment that might be tricky, but it might also pinpoint something. When you have this REALLY slow form opening (the ones that take over 30 seconds), set up this situation.

Using your Remote Desktop setup, prepare to do testing for the case where the FE being run is physically on the same machine as its BE file.

Start Task Manager and switch to the "Processes" display. Normalize the window so that you can see some of your desktop.

Open your database. Normalize the window (if possible) so that you can see TM and your DB at the same time on your desktop.

Now launch one of the "ugly" forms. (Note: To figure out all of this, you might have to do this more than once.)

Immediately use the Task Manager as follows: Click in the CPU, Disk, and Network columns to identify the highest users of those resources. Also click the Memory, though I'm not betting on that one being an issue. Since your FE and BE are on the same machine, your Network load should be fairly low.

Switch Task Manager to "Performance" and look for peak usage in each of those categories. You want to identify whether you have tripped over a bottleneck somewhere. TM will show you broad-brush ideas of where you are eating resources.

From your Windows "Start" button (lower left corner), Click, scroll to Windows Adminstrative Tools, expand that, and start Resource Manager.
Again, while trying to load one of your stubborn forms, start it and switch to RM. In the menu, you can focus on CPU, Disk, Network, Memory, or the Overview screen. You want to see which files your task is hitting and how hard.

I'm trying to find out whether, when this craziness hits, you are disk-bound, network-bound, or CPU-bound. In a "normal" profile I would expect a brief burst of disk activity that might be too quick to see in detail (though Task manager's performance page DOES keep a history of the past several seconds). Then you would have a burst of network activity alternating with or parallel to CPU activity. Resource Monitor might tell you that the "network socket" you are using goes through the Loopback connection because the BE is on the same machine with the FE.

In a well-behaved system, those CPU and Network bursts would also be short-lived. In your case they might not be. It would also be interesting to know whether the CPU hog was MSACCESS itself or the ACE engine in a separate thread. In a brief load, you might not be able to see that, but for something running very long, RM might call it out separately. The trick here is to figure out what is working hardest.
i am working on windows 10 and Access 2016,
just opened one of my other DB programs, the speed between forms is not bad but must say not as it used to be
the speed between forms and from design to view is the same on my laptop, from remote desktop and the same for other remote desktop users from between forms,

when running the performance test, one of the problematic forms runs at 23% CPU utilization,
Ethernet runs at send 1,6 Kbps, and receive avg of 7 KBPS
there is very short network bursts for a second or 2 only


on the remote desktop, very similar
I had the IT manager look at the figures, local and remote, he seems to be happy with the speed

i could not perform the recourse manager task because of permissions on the network
 

CarlettoFed

Member
Local time
Today, 07:19
Joined
Jun 10, 2020
Messages
119
I think the only possibility to try to help you would be to have the FE and BE files available for testing.
 

Users who are viewing this thread

Top Bottom