 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Multiuser / Networking / May 2008Slow running database
Hello All, I am having a problem with a database running on a network. Using any part of the database seems to be slow even when only one person is accessing it. I have a separate file housing the tables. My main program has links to the tables in the table database. I have created an mde file and each user has this file on the desktop. When any user opens the mde and tries to open a form the form can take up to a minute to open. This was not an issue when the database was created on a local drive. Would the program run faster if I moved the data to SQL and created a link to the SQL database instead of linking to an Access database? Any suggestions would be greatly appreciated. Rob >I am having a problem with a database running on a network. Using any part >of the database seems to be slow even when only one person is accessing it. [quoted text clipped - 5 lines] >moved the data to SQL and created a link to the SQL database instead of >linking to an Access database? Any suggestions would be greatly appreciated. This should not be going so slowly, unless your forms are doing a LOT of database access (like with many long comboboxes). Before you take drastic measures, some things to check: - is the network slow in general? Can you navigate folders and copy files quickly? - are both the front-end and back-end databases recently compacted? - is Name AutoCorrect turned off in both databases? See Allen Browne's excellent reference http://allenbrowne.com/bug-03.html. - There have been reports of slow performance when the back-end database uses a long name or folder paths with long names. Just to eliminate this possibility, try placing the back-end database in the server's root folder, or at least with a series of folders with short names (8 characters max, no spaces). Make sure that the back-end database has a short name too. See http://support.microsoft.com/search/default.aspx?mode=r&query=access+long+file+n ames+performance&catalog=LCID%3D1033&1033comm=1&spid=global. Others might weigh in with more suggestions too. Armen Stein Microsoft Access MVP www.JStreetTech.com Armen, Name Autocorrect was already turned off. I do not have control of the folder names and placement of the database - IT controls this. This is on a WAN and the users in one particular location have speed issues accessing data at our central site. We also have issues accessing data at their site so I think it might have to do with their site. I am going to try useing replicas even though I know that ove a WAN it could be problamatic. I only have four people accessing the program and the two that do all of the data input are at the same location so I think that the replicas should be fine. I was also told to look into setting the database up on a Terminal Server. Thanks for the information. > >I am having a problem with a database running on a network. Using any part > >of the database seems to be slow even when only one person is accessing it. [quoted text clipped - 33 lines] > www.JStreetTech.com > >This is on a >WAN and the users in one particular location have speed issues accessing data [quoted text clipped - 4 lines] >the same location so I think that the replicas should be fine. I was also >told to look into setting the database up on a Terminal Server. Ah, it's on a WAN. Access doesn't perform well across a WAN, as it is a file-server approach where all the actual processing is done on the front-end PC, requiring all the data to be sent over the wire. Terminal Server is indeed your best option if you don't want to change the back-end architecture. Many MVPs on this newsgroup have had good success with it - Arvin Meyer is one that comes to mind. If you do want to be able to operate over the WAN but stick with your Access front-end on each local PC, then upsizing the back-end database to SQL Server is a good option. Some work is required to get the best performance, but it can be a very good solution. We've used this architecture for many projects at our shop, including one used internally at Microsoft. For a few tips on this, see "The Best of Both Worlds" slide deck at: http://www.jstreettech.com/cartgenie/pg_developerDownloads.asp. Armen Stein Microsoft Access MVP www.JStreetTech.com >Terminal Server is indeed your best option if you don't want to change >the back-end architecture. Many MVPs on this newsgroup have had good >success with it - Arvin Meyer is one that comes to mind. As have I. We had users several thousand miles away happily using the system. Tony  SignatureTony 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/ I've been successful running a large Access XP application on Terminal Server. The only thing that is slow is opening .pdf and .tif files. My setup works with one front end but I'm wondering if most TS developers give each user their own front end? Patrick. On Sat, 19 Apr 2008 07:21:00 -0700, Rob <Rob@discussions.microsoft.com> wrote: >This is on a >WAN and the users in one particular location have speed issues accessing [quoted text clipped - 8 lines] >the same location so I think that the replicas should be fine. I was also >told to look into setting the database up on a Terminal Server. Ah, it's on a WAN. Access doesn't perform well across a WAN, as it is a file-server approach where all the actual processing is done on the front-end PC, requiring all the data to be sent over the wire. Terminal Server is indeed your best option if you don't want to change the back-end architecture. Many MVPs on this newsgroup have had good success with it - Arvin Meyer is one that comes to mind. If you do want to be able to operate over the WAN but stick with your Access front-end on each local PC, then upsizing the back-end database to SQL Server is a good option. Some work is required to get the best performance, but it can be a very good solution. We've used this architecture for many projects at our shop, including one used internally at Microsoft. For a few tips on this, see "The Best of Both Worlds" slide deck at: http://www.jstreettech.com/cartgenie/pg_developerDownloads.asp. Armen Stein Microsoft Access MVP www.JStreetTech.com >My setup works with one front end but I'm wondering if most TS developers >give each user their own front end? Everyone gets their own FE no matter if on LAN or TS. Tony SignatureTony 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/ Thanks for your advice Tony. Patrick. "Patrick Jackman" <pjackman@wimse.com> wrote: >My setup works with one front end but I'm wondering if most TS developers >give each user their own front end? Everyone gets their own FE no matter if on LAN or TS. Tony SignatureTony 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/ Patrick, Realize that this may not apply, but in addition to the other comments, if your users have roaming profiles, then having the file on their desktop is just another way of saying that it is on the network, and you will have speed problems with that configuration as well. Where I work, everyone has a roaming profile, so they can sit down at any empty cube and log on. In that case, I generally place my applications in a folder in the C:\Program Files\ directory of their PC and place a shortcut to my config control application that will check the C:\Program Files\myApp\ folder to see if they have the most recent version of the application. If not, it copies that file from the network to their local drive and then kicks off the application. HTH Dale > I've been successful running a large Access XP application on Terminal > Server. The only thing that is slow is opening .pdf and .tif files. [quoted text clipped - 41 lines] > Microsoft Access MVP > www.JStreetTech.com >Where I work, everyone has a roaming profile, so they can sit down at any >empty cube and log on. In that case, I generally place my applications in a >folder in the C:\Program Files\ directory of their PC I was under the impression that most IT departments didn't allow update Access to the Program Files folder. Thanks for the reminder about roaming profiles. I keep forgetting that such exist and how they work. Tony SignatureTony 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/ >>Where I work, everyone has a roaming profile, so they can sit down at any >>empty cube and log on. In that case, I generally place my applications in a >>folder in the C:\Program Files\ directory of their PC > > I was under the impression that most IT departments didn't allow > update Access to the Program Files folder. I believe this is common, yes. That's why I've switched to putting the FE in C:\Documents and Settings\AllUsers\ somewhere (usually a folder under Application Data) SignatureJoan Wild Microsoft Access MVP >> I was under the impression that most IT departments didn't allow >> update Access to the Program Files folder. > >I believe this is common, yes. That's why I've switched to putting the FE in >C:\Documents and Settings\AllUsers\ somewhere (usually a folder under Application Data) Agreed. I always do the same and recommend such. Tony SignatureTony 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/ You are correct, but our IT guys are pretty flexible, and have created a folder for our use within that Program Files folder that we have full permissions to. But I like Joan's idea about using C:\D & S\All Users\ and may take a look at that. SignatureDon''t forget to rate the post if it was helpful! email address is invalid Please reply to newsgroup only. > >Where I work, everyone has a roaming profile, so they can sit down at any > >empty cube and log on. In that case, I generally place my applications in a [quoted text clipped - 7 lines] > > Tony >You are correct, but our IT guys are pretty flexible, and have created a >folder for our use within that Program Files folder that we have full >permissions to. Say what!?!?! IT guys and flexible is clearly an oxymoron. And congratulations. You're one of the few who've ever stated such. Tony SignatureTony 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/ It's not the permissions that are the real problem. The real problem is that most IT departments will re-image your Program Files and Windows folders. 'Application data' is in your roaming profile and is copied down from the server every time you log in. That can take a while for a 1GB file, even on a 1Gb network. For databases, sometimes "local settings\application data" is a better choice. (david) > You are correct, but our IT guys are pretty flexible, and have created a > folder for our use within that Program Files folder that we have full [quoted text clipped - 16 lines] >> >> Tony > It's not the permissions that are the real problem. The real problem > is that most IT departments will re-image your Program Files [quoted text clipped - 4 lines] > a 1GB file, even on a 1Gb network. For databases, sometimes > "local settings\application data" is a better choice. Thanks for that - but All Users doesn't have a local settings folder - perhaps I've misunderstood you. SignatureJoan Wild Microsoft Access MVP > but All Users doesn't have a local settings folder Well, it will if you create one :~), but I don't think that All Users roams? "Local Settings" is excluded from a roaming profile by default because there is an explicit (default) setting in the profile template that excludes the "Local Settings" folder. It doesn't matter who creates it or why. But I was thinking of personal profiles, as suggested by Garry Robinson as a security model. (david) > It's not the permissions that are the real problem. The real problem > is that most IT departments will re-image your Program Files [quoted text clipped - 4 lines] > a 1GB file, even on a 1Gb network. For databases, sometimes > "local settings\application data" is a better choice. Thanks for that - but All Users doesn't have a local settings folder - perhaps I've misunderstood you. SignatureJoan Wild Microsoft Access MVP Appreciate the info david; I don't deal much with roaming profiles. SignatureJoan Wild Microsoft Access MVP >> but All Users doesn't have a local settings folder > [quoted text clipped - 21 lines] > Thanks for that - but All Users doesn't have a local settings folder - > perhaps I've misunderstood you.
|
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.