MS Access database runs extremely slow on Citrix Presentation Server
Config A (The configuration that works): HP Proliant DL360; Windows 2000 SP4; Citrix Metaframe XP Server; Microsoft Access 2000 SP3.
Config B (The configuration that doesn't work): HP Proliant DL380 G3; Windows 2003 SP1; Citrix Presentation Server 3; Microsoft Access 2003.
Issue: We have an Access 2003 database (.mdb file) housed on a Windows 2003 server separate from the two servers listed above. Our Citrix clients, running Windows XP, are are both local and remote. On Config A, when the Citrix client launches the .mdb file, the response time ranges anywhere between 15 seconds to 3 minutes as compared to approximately 5 seconds on Config B. clients on Config A access the .mdb file via the Citrix Program Neighborhood. clients on Config B access it through the citrix web front end using I.E. 6.0 SP2. The Config A, Config B and the .mdb host file servers are on the same subnet and are in the same physical location.
Does anyone know what could be causing the latency issues with the Access db on the Citrix Presentation Server and how to resolve it?
Config B (The configuration that doesn't work): HP Proliant DL380 G3; Windows 2003 SP1; Citrix Presentation Server 3; Microsoft Access 2003.
Issue: We have an Access 2003 database (.mdb file) housed on a Windows 2003 server separate from the two servers listed above. Our Citrix clients, running Windows XP, are are both local and remote. On Config A, when the Citrix client launches the .mdb file, the response time ranges anywhere between 15 seconds to 3 minutes as compared to approximately 5 seconds on Config B. clients on Config A access the .mdb file via the Citrix Program Neighborhood. clients on Config B access it through the citrix web front end using I.E. 6.0 SP2. The Config A, Config B and the .mdb host file servers are on the same subnet and are in the same physical location.
Does anyone know what could be causing the latency issues with the Access db on the Citrix Presentation Server and how to resolve it?
ASKER
Thanks very much for your feedback. Youve listed very good actionable measures to reduce corruption and help database response times. However, since we are using Citrix, the MS Access application is installed on the Citrix server itself. Therefore, (and please correct me if Im wrong) we cannot have the individual front ends on each machine.
Also, I failed to mention on the previous post that when Citrix clients launch the .MDB file (regardless if they go through the Citrix Program Neighborhood or through the Citrix web front end), they are actually launching a shortcut to an .MDB file located on a different server, which in turn calls the SQL backend tables located on yet another different server. In other words, we are talking about 4 hops here: client to Citrix to .MDB host server to SQL server. This setup works fine on the Config A server though. In addition, we have other non-Access applications on the Config B server that are not experiencing this lag time.
Any thoughts on what could be causing the latency issues with the Access db?
Also, I failed to mention on the previous post that when Citrix clients launch the .MDB file (regardless if they go through the Citrix Program Neighborhood or through the Citrix web front end), they are actually launching a shortcut to an .MDB file located on a different server, which in turn calls the SQL backend tables located on yet another different server. In other words, we are talking about 4 hops here: client to Citrix to .MDB host server to SQL server. This setup works fine on the Config A server though. In addition, we have other non-Access applications on the Config B server that are not experiencing this lag time.
Any thoughts on what could be causing the latency issues with the Access db?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Doh!!! Yes, you are correct, I did get Config A and Config B mixed up on my original post. I will be contacting Citrix with this issue. I wanted to make sure that this was not a known issue with MS Access databases and Citrix. Speaking with their Tech Support appears to be the way to go and the solution this time. I will assign the points to you. Thank you for your assistance with this matter.
Hopefully tech support will know more about their product than you do. I find Asking for a supervisor or for the question to be escalated helps if they are not helpful. After that, I find a fax from an attorney usually gets me a very knowledgeable person almost immediately. (I am a number of Prepaid legal so those letters are part of my benefits.)
You're welcome. Glad to help and thank you very much for the points with "A" grade!
Happy Computing!
Nelson
You're welcome. Glad to help and thank you very much for the points with "A" grade!
Happy Computing!
Nelson
Reduce Corruption, Speed up database
All databases are heavy network users. To reduce the risk of corruption and speed up the database, these are things to do for any database:
1: Make sure your hardware is in top shape, all computers are routinely vacuumed to remove dust and lint and your network is set up correctly. Have all the machines on the same domain.
2: Have individual front ends on each machine. I created a database that checks the server for a newer copy of the front end, downloads it if needed, then runs it. You can get a copy of it at: http://www.thenelson.name/, Updated Front End
3: Create a mapped drive for the backend or place the backend folder as close to the root folder and use only UNC path to the backend. Some people (and Microsoft) say the mapped drive is better, some say the UNC path is better. I have found it depends on the network setup.
4: Have the name of the backend and the name of the folders in the UNC path to it as short as possible meeting dos 8.3 naming specs and with only alpha numeric characters. \\server1\C:\db\db1_be.mdb
5: Don't run a local copy of the front end on the machine that has the backend -- best to have the backend on a true server running a domain with all workstations subscribed to the domain. You might get by running home version for two computers, maybe three sharing a very small, simple Access database on the home version although you may run into sharing problems. In a work situation, running a multi user Access database, all workstations should be running the pro version. It you have less than about five workstations, you might get away with the backend being on a system running pro but more than that or with a complicated database, you need a domain and the sever running a sever OS. Get up to a dozen heavy users or a couple of dozen light users and the server should be a true server, be dedicated to only serving the one database and the back end should be SQL Server (or SQL Server Express).
All of this is cutting down the number of times accesses need to be qualified, files need to be opened and closed and reduces the complexity of parsing the path all of which reduces the chance of corruption and speed up the database.