none
Access slows down RRS feed

  • Question

  • Using Office 2016 on a Domain for some users Access slows down.

    There are 15 users on a Windows Domain (2019 Server) using a Access Database that resides on Synology NAS. For 3, (Three only) users the database is slow but not the other users. 

    All the computers are 14 months old, Win 10, i5 processors with 8Gb memory. Wiring is all Cat 5E. We just replaced the Gateway and switch.

    One user that is experiencing slowness logged into her computer as a local user did NOT experience slowness. As soon as she went back to the domain it was slow.

    Word, Outlook Excel are NOT slow,

    None of these users are Administrators but they all have read/write permission.

    I'm looking for ways to track down the cause of this issue.

    Tuesday, March 3, 2020 1:22 PM

All replies

  • You're referring to Microsoft Access databases allowing down?

    Firstly, users should have read/write and delete permissions.

    Secondly, are the databases properly split and each user provided their own local copy of the front-end?


    Daniel Pineault, 2010-2019 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net

    Tuesday, March 3, 2020 3:26 PM
  • Yes Microsoft Access Database

    The database resides on the NAS the users have as much rights as possible. The NAS is updated from the Server every 6 hours (although users do not change much if at all)

    Each user has their own front end that resides on their "C" drive. The database is split into different databases, I can only assume they are properly split, as the db was professionally made.

    Remember only 3 of 15 users experience the issue of slowing down.

    I appreciate your help

    Tuesday, March 3, 2020 4:19 PM
  • >>I can only assume they are properly split, as the db was professionally made.

    Hahaha! After spending a career of cleaning up behind so-called professionals, I never assume anything was done right. Not even if I was the professional. We all make mistakes and hopefully learn as we gain experience.

    That said, I have seen certain users have issues when their profiles have been corrupted in some way. Deleting the profile and recreating it usually fixes the problem.


    Bill Mosca
    https://wrmosca.wordpress.com https://groups.io/g/MSAccessProfessionals


    Tuesday, March 3, 2020 4:35 PM
  • I hate to say I "assume" you mean delete their profile on the server.

    I will do this and see what happens.

    thanks

    Tuesday, March 3, 2020 4:43 PM
  • I hate to say I "assume" you mean delete their profile on the server.

    I will do this and see what happens.

    thanks

    Yup.

    Bill Mosca
    https://wrmosca.wordpress.com https://groups.io/g/MSAccessProfessionals

    Tuesday, March 3, 2020 5:20 PM
  • please explain this:

    One user that is experiencing slowness logged into her computer as a local user did NOT experience slowness. As soon as she went back to the domain it was slow.

    - what is meant in your case by 'local user' versus 'domain' ?

    ps Word, Outlook Excel are NOT slow: they do not link to a back end file so that is to be expected....

    Tuesday, March 3, 2020 11:37 PM
  • One user logged in as computer name\ user name and did not experience slowness. then logged in as domain name\user name Access was slow.
    Tuesday, March 3, 2020 11:56 PM
  • Then you need to start looking at group policies, security groups, etc...  compare the various users and their domain accounts.  What groups are they part of, or not.

    Daniel Pineault, 2010-2019 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net

    Wednesday, March 4, 2020 1:55 AM
  • if you still have this problem and the other posts did not resolve....

    it would seem this side-by-side trial is a key comparison and we should identify what is different between the two modes.

    Do be sure your benchmark is identical...some tasks in Access can be much slower than other tasks such as elaborate sorts of large record sets and so if 1 is doing that but the other is not then it isn't a good benchmark....

    verify that they have the exact same FE file, that FE file size is the same (that's a key thing to note)….to be sure their FE is not bloating during use...that would indicate it is an Access issue...

    I must admit that I don't follow your infrastructure reference - - - logged in to..?  is this Active Directory domain - - it is not Access terminology so...

    But I have had the experience in larger user environments where slow for 1/some but not others - - as the database guy I then have to turn it over to the IT guys.....network, permissions, not sure what they do and I don't like finger pointing but if you do have apples to apples then there is something out there affecting thru put / handshaking......


    Wednesday, March 4, 2020 1:59 AM
  • They all are only in the "Users" group, no other.

    This is an Active Directory domain, you can log into the domain by using domain\user or log into the computer by using computer\user

    I do not know what you mean by a side by side trial or how we could do that

    Wednesday, March 4, 2020 2:09 AM
  • Your front-end establishes a Persistent Connection as soon as it starts up?

    Have you verified the NAS security settings?

    Also, I've encountered major performance issues using NAS devices.  Have you tried placing your backend on a Windows server to see if that made any difference,


    Daniel Pineault, 2010-2019 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net

    Wednesday, March 4, 2020 11:45 AM
  • Your front-end establishes a Persistent Connection as soon as it starts up? Yes the problem is not until later.

    <o:p>I have discussed this issue with Synology they just say it is the database</o:p>

    <o:p>The server was not designed for storage all our data is on the NASs</o:p>

    Wednesday, March 4, 2020 12:45 PM
  • side by side meant the user who tried 2 ways and one is slow.  if they are identical front end files and doing the identical tasks then it is an ideal comparison.

    if this is true it really looks like an AD issue.  You might take this topic to the AD forum.

    Wednesday, March 4, 2020 9:52 PM
  • Probably will be hard to compare side by side as users each have their own desks and could be working a different client, but we are working on a way to compare.

    Do you have a link for the AD forum?

    thanks

    Wednesday, March 4, 2020 10:05 PM
  • If possible, can you open any linked table, minimize it, and THEN run + use the forms?

    This so called persistent connection can often help and fix such issues. There is a chance that this suggestion will not help, but if you can open some table in the front end (a linked table), and simply minimize the table, and then launch the startup form, then this may very well fix your program. It is certainly worth a try if possible. This trick and suggestion can often help in "huge" ways. 

    Regards,

    Albert D. Kallal (Access MVP 2003-2017)

    Edmonton, Alberta Canada

    Friday, March 6, 2020 7:53 PM
  • All we have on the desktop is the front end DB it opens all the other tables
    Friday, March 6, 2020 8:06 PM
  • Maybe a silly question, they all seem to have the same hardware.

    Do they all print to the same printer?  Do they all have the same printer driver?


    If this post answered or helped you find the answer to your question, please mark it as such for other Forum users knowledge.

    Friday, March 6, 2020 8:10 PM
  • all on a domain all have new 14 months ago Win 10 machines, all same memory

    All print to a large HP printer (network)

    everyone has Office 2016 

    They are a non profit did not want to replace Office

    Friday, March 6, 2020 8:17 PM
  • Does not answer the question. 

    VERY often a persistent connection will fix this issue. So, if you can open one form, or a table that is based on a linked table, and THEN run the application, your issue will go away. This issue of "large" delays has been WELL known since Access 2000 came out (that is a long time). 

    On many office networks, the persistent connection does not necessary help, but in a HUGE number of cases it 100% eliminates the issues of some machines running slow, and others working fast. In fact, in MOST cases the symptom is:

    One user in the database. It works fast. After the 2nd user starts working, then it runs really slow for 2 or more users. The reason for this huge slow down is Access often tries to close, and then open the connection to the back end. Thus the network, the server, windows 10 etc. ALL COMES into play. Then it not the speed of the network, but huge massive amounts of security and all kinds of domain stuff that I could write about for 100+ pages of technical reasons for this. 

    So, what a persistent connection does is force the connection to stay open at all times, and then that huge long list of OTHER things that occur when Access tries to open a table etc. is thus eliminated. 

    Often, an application will have a persistent connection if some startup form, or some main form is open at all times, and it is linked to the back end. As I stated, this does not always fix this problem, but you REALLY want to answer this question.

    This is like troubleshooting a car that don't work. You can ask 100's of questions, but then we all find out that someone forgot to check if the battery is dead. It takes less then  minute, and all your problems could be solved in 1 minute of a simple test. Without a answer to this question you MAY HAVE WELL missed the fix to your problem already!!!

    The other common issue is workstations without a default printer, or one that is pointing to a non existing printer on the network. So, often you see 2-3 extra printers that were installed on a workstation, but the printers no longer exist, or point to printers that don't exist. This can again cause HUGE delays in Access forms, since when a form is loaded, Access makes requests about the printer that it MIGHT have to use for printing of that form. If the printer is non existent, or some network printer that is "difficult" to connect to, then large delays appear in the form loads, and yet other work stations work fast.  Again, like the car battery, or the persistent connection, such things take 1 minute to check, but if you miss such simple things, then you can spend days looking for a solution.

    Often, this is like a episode of Dr. House. This is like a medical mystery, and often it 1 or 2 small things. Often it's something much more complex. However, without known answers to these simple questions, then troubleshooting not only becomes a guessing game, but a game in which missing a simple answer and solution will cause you to skip such simple things, and now you doing a deep dive into your networks and systems when none was required.

    So, tops in the list:

    Persistent connection - do you have one?

    Network printers, and/or default printers. Try setting up a local printer (even if it is NOT a real printer, but say a PDF printer). MAKE it your default. 

    Next up is virus software running on a workstation. Often this is the issue - the virus software is constant scanning the workstation, the network, and it plays havoc with Access. So, perhaps a 2 minute test in which you disable the virus software. 

    If creating (having) a local printer, and it been set as the default printer before you launch access does not help, then that persistent connection should be looked at. After that, you likely going to have to look at any virus software (say, add exceptions for access, and maybe the folder used for the front end part). After that, then you have to start looking at network systems etc. But then again, a few quick and simple tests will yield valuable information here.

    Regards,

    Albert D. Kallal (Access MVP 2003-2017)

    Edmonton, Alberta Canada


    Sunday, March 8, 2020 12:00 AM
  • This will take some time to get answers, I will try
    Sunday, March 8, 2020 12:06 PM
  • Hi Playpar,

    I'm more of suspecting as Albert mentioned about Anti-Virus. I would suggest you not only check on one end, check every PCs and Server as well.

    Your Anti-Virus may have an aggressive scan for Access connection. If true, you can try to put an exception.

    HTH 

    Monday, March 9, 2020 1:22 AM
  • This will take some time to test as the problem only happens off and on, plus I do not not use the database, others in the office complain. We will test it as you suggested.

    we all use Microsoft Defender as the anti virus, they should not have anything else on the computers, we will check that today alone with the printer.

    Monday, March 9, 2020 11:17 AM
  • Have you started with the "obvious" ?

    Is the Synology capable of handling 15 users...it might be high end it might be a small -home level NAS with a tiny CPU/memory

    Have you checked the Network..and i mean ping (latency), file transfer speed.

    Last but not least try to run exactly the same workload on the "bad" and on a "good" machine.


    Monday, March 9, 2020 11:28 AM
  • the March 3 post stated: One user logged in as computer name\ user name and did not experience slowness. then logged in as domain name\user name Access was slow.

    - I really would recommend you find some strong Active Directory advice - surely MS has a community...

    Monday, March 9, 2020 12:34 PM
  • Yesterday we disabled Anti-Virus on ALL work stations and removed any printers that are not the default printer.

    This morning one user again had the hour glass waiting for Access while other users did not have a problem.

    We will work on the persistent connection today (not sure how)

    This issue is NOT a consistent problem, it happens different times of day to different people (normally only 3 people but has happened to everyone). We can go hours without issue then slows down. 

    Each user is working on a different client so are not on the same form as others.

    We were told this is NOT an AD issue as once the user authenticates with server the server is pretty much out of the picture.

    The NAS is new and has extra memory, Synology says the NAS is not the issue.

    History:

    We have been using this Database, Server and NASs for more then 10 years without issues. The database has had additions, updates, edits, etc. over the years and is of course getting bigger, but not considered large. 

    In January 2019 new Win 10 computers were purchased. 

    This issue of Access slowing down started in September 2019, and continues

    In December 2019 a new 2019 Standard Server, replaced the old 2008 R2 server.

    In January 2020 New faster NASs replaced the old ones (2 NASs, one syncs with the other each night), two new Ubiquity switches were added. A Unfi gateway was added January 2019

    The problem still continues even with new equipment.

     
    Tuesday, March 10, 2020 1:36 PM
  • When was the last time the database was compacted? I usually plan this as a monthly task.

    When you compact,

    1. Make sure everyone is out of the database (ie, not locking file exists.
    2. copy the database to your local drive
    3. compact the local file
    4. replace the server file with the newly compacted local file.

    Bill Mosca
    https://wrmosca.wordpress.com https://groups.io/g/MSAccessProfessionals

    Tuesday, March 10, 2020 2:39 PM
  • Because your network infrastructure had changed so much, you can't compare the existing situation to your previous baseline, as that baseline no longer exists: server changed, NAS devices changed, switches changed, PCs changed.  

    No one is going to say, yes it's our fault, synology, IT ... Will never say is their fault, so you can't rule anything out until you properly test for yourself.  This is why I suggested testing moving the backend to a server.

    Is everyone connect on the same LAN?

    Is everyone connected by wires, no wireless (and no wireless jumps in between)?

    Are all your users running the same bitness of Access?

    How big is your backend currently?

    Each user had their own local copy of the front end?  No sharing of a single common file!

    As for a persistent Connection, it takes 5 minutes to setup, refer to: https://www.devhut.net/2012/09/29/ms-access-persistent-connection-in-a-split-database/ , it can be done using code, but I had an issue with that in the past so I recommend the hidden form approach instead.


    Daniel Pineault, 2010-2019 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net


    Tuesday, March 10, 2020 7:29 PM
  • We are pretty much in a situation where there is not much else I can try.

    Yes all on the same LAN

    All hard wired

    the main database is 178000 kb fairly small, however there are 17 different reports or add on's.

    Everyone has the same front end.

    We were told NOT to do the persistent connection, we a not allowed to touch the database folder on the NAS.

    The sever was not designed to hold any data, it only has one drive for the OS, besides if it would be moved to the server all the links would probably need to be changed as the path changes, we could not do that.

    Now I'm told it is also slow when opening a Word document from within Access. There are links in the database for a (Word) document, when the link is clicked it takes 10 seconds to open. Yet when we open File Explorer go the the folder where the (same) document is it takes only 3 seconds to open the same document.

    I do not understand this but not much else I can do

    Sunday, March 15, 2020 12:31 PM
  • A Persistent Connection is a database thing and is of no concern of IT, just implement it as it is fundamental to any split database. Point then to one of the article on the subject.

    If your IT department doesn't allow it, get your manager to get it authorized.

    Not allowed on the server?  You need to try some alternate location, server, share of of another PC, anything just to determine if the NAS is in any part responsible for the issue.  This is basic troubleshooting and your IT department should understand this.  If they don't, get your manager to tell them that  this needs to be done to isolate the issue.  One again, this shouldn't be an issue.

    That all said, the minute you stated that word documents are slow to open, this clearly indicates NAS, network issues not database!  So an IT issue.

    I'd be looking at the NAS wires (makes sure they're gigabit), check the switch speeds, look at network saturation, ...  All the fun stuff.  Many NAS device have consoles where you can check the health and other aspects, is be looking that over...


    Daniel Pineault, 2010-2019 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net



    Sunday, March 15, 2020 2:22 PM
  • >>Removed any printers that are not the default printer.

    But I also asked that you test with a default printer that is NOT a network printer. And I also stated that you don't have a physical printer, then make the default a XPS or a pdf printer. So, getting rid of network, or printers that don't exist anymore is VERY good, but the suggest was ALSO to test and ensure that the workstation in question HAS a default printer. And SPECIFIC to test with a printer that is NOT a network one. Since in most cases a workstation does not have a actual printer, then I provided additional information that you can STILL setup a default printer and STILL setup one that is not network based EVEN when the workstation does not have an actual printer attached. 

    So, based on your information - still all wrong, and still not tested correctly.

    Regards,

    Albert D. Kallal (Access MVP 2003-2017)

    Edmonton, Alberta Canada

    Sunday, March 15, 2020 3:06 PM
  • Well, you still not tested the workstations without a network printer, and the default printer being a non network printer.

    >we were told NOT to do the persistent connection

    What do you mean? This is like IT folks telling staff not to use capital letters in word because it uses extra toner when printing.

    Or that you not supposed to use double line spacing in word? The persistent connection is something the person who created the database is to setup. Not anything to do with the IT department, any more then them telling you to not use double spacing when typing a word document. 

    It not clear why IT is telling staff how they are to type their letters, or what and how should people type into Access or Excel or word.

    So, what you type into word, or how the forms or columns or whatever you have in Access is something that the people using Access and who created the Access application is to setup and change - not IT folks. The IT department can no more change a persistent connecting in Access then they can be asked to go and edit and correct mistakes in how the HR department writes their annual performance letters. 

    The problem seems more of people now following basic instructions in terms of troubleshooting.

    Regards,

    Albert D. Kallal (Access MVP 2003-2017)

    Edmonton, Alberta Canada

    Sunday, March 15, 2020 3:17 PM