ACCESS 2003 really slow for offsite users
Yes, I know ACCESS is meant for local usage, but where I am insists that our East Bay office use the database. However, they complaint about how slow it is, etc. Does anyone have any suggestions on how to speed up data-entry for off site users? I have it set up now that a .bat file is run to create a local copy of the front-end, but they still complain and it sometimes simply freezes.
Sandra
Sandra
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
Sandra,
<<It is even slow on the Citrix.>>
That's odd...usually Ctrix works well, even in low bandwidth conditions because only KVM (Keyboard Video and Mouse) is running over the connection.
As far as Access is concerned, it's running on the local LAN and should get the same performance as if you were in the office.
Jim.
<<It is even slow on the Citrix.>>
That's odd...usually Ctrix works well, even in low bandwidth conditions because only KVM (Keyboard Video and Mouse) is running over the connection.
As far as Access is concerned, it's running on the local LAN and should get the same performance as if you were in the office.
Jim.
ASKER
Jim that is what I was told and hoped Citrix would solve the problem, but it did not. I do not know enough about Citix to understand how it is configured but it does not perform well either. We are going to create local network versions for the offsite office across the country and then upload into the master overnight. I have used this methodology at other places and it does work. I do have to emphasize to them that the database must be in a stable condition, that is, no additional structural changes as it would be cumbersome to maintain. Wish me luck!
Sandra
Sandra
<< I do not know enough about Citix to understand how it is configured but it does not perform well either. >>
That is really odd...there's no reason it should not unless the Citrix Server is under powered.
<<We are going to create local network versions for the offsite office across the country and then upload into the master overnight. I have used this methodology at other places and it does work. >>
Yes, that's an approach. Little more complicated by the fact that Microsoft dropped indirect replication from Access, which solved problems like this nicely, but one of the reasons they did that is it always comes down to the problem of how do you go about resolving conflicts? That and that RDP/Citrix worked well and was more real time, so replication ended up as a seldom used feature.
<<I do have to emphasize to them that the database must be in a stable condition, that is, no additional structural changes as it would be cumbersome to maintain. >>
That will be difficult with the approach your taking.
I'm not sure what the situation is, but you really should be looking closer at why Citrix doesn't perform well as the easist path. It has the least impact on the application and is generally plug and play.
It works so well in fact that in many compainies, this is the way they normally operate on a day to day basis for every office they have. The data center is either hosted or a non-office location.
Jim.
That is really odd...there's no reason it should not unless the Citrix Server is under powered.
<<We are going to create local network versions for the offsite office across the country and then upload into the master overnight. I have used this methodology at other places and it does work. >>
Yes, that's an approach. Little more complicated by the fact that Microsoft dropped indirect replication from Access, which solved problems like this nicely, but one of the reasons they did that is it always comes down to the problem of how do you go about resolving conflicts? That and that RDP/Citrix worked well and was more real time, so replication ended up as a seldom used feature.
<<I do have to emphasize to them that the database must be in a stable condition, that is, no additional structural changes as it would be cumbersome to maintain. >>
That will be difficult with the approach your taking.
I'm not sure what the situation is, but you really should be looking closer at why Citrix doesn't perform well as the easist path. It has the least impact on the application and is generally plug and play.
It works so well in fact that in many compainies, this is the way they normally operate on a day to day basis for every office they have. The data center is either hosted or a non-office location.
Jim.
ASKER
Jim, believe me, I really do not want to go the duplicate databases/upload or any messy avenue if I can avoid it. Our Citrix "expert" actually has been looking into this issue for several weeks now, but cannot figure out why it does not work as you indicated. I am just desperate to get this project going. what they really need is a custom, .net application with a server backend that can handle what is bascially an enterprise function as users eventually will be nation-wide, then world wide and I don't even want to think about the problems that will arise under that sceanario. Thanks for the dialog and there will be future questions on this whole issue.
Sandra
Sandra
<<Our Citrix "expert" actually has been looking into this issue for several weeks now, but cannot figure out why it does not work as you indicated.>>
I would suggest that they login to the Citrix server on the local lan to eliminate any WAN issues.
If performance is still poor, then it's the Citrix server, the local LAN, or the app. That can be pinned down further by using the app locally. If it works fine from standard stations, then look at the LAN connection to the Citrix server and the Citrix server itself, which should have 1-2GB per remote user and no more then 20-30 users on it (I'd use task scheduler to see if it's being overworked on CPU or memory).
Also check the setup under Citrix; each user should still have their own copy of the FE by placing one in a directory mapped by account (i.e. X:\myapp.MDB, X: being different for each user).
Even with that, be aware of any references in your app that use C:\. If your using a library app in conjunction with the main app, make sure it's mapped as X:\myLib.MDB in references.
<<what they really need is a custom, .net application with a server backend that can handle what is bascially an enterprise function as users eventually will be nation-wide, then world wide and I don't even want to think about the problems that will arise under that sceanario. >>
Really depends on the number of users. If 20-30 concurrent users is it, then despite location, you should be fine with an Access/JET based app. If anything more then that, then I'd be looking at a different BE for sure.
Beyond that, switching to .Net in of itself will gain you some performance, but mainly it's a matter of developing an app in terms of client/server rather then the way most Access apps are developed.
For example, you would not bind an entire table to a form. Also things like pushing all the work server side with stored procedure and triggers, and using things like views.
So a middle of the road solution of Access FE with a SQL Server backend might be quite workable. To get an idea on that, look at some of the tips here:
The best of both worlds
http://www.jstreettech.com/cartgenie/pg_developerDownloads.asp
Jim.
I would suggest that they login to the Citrix server on the local lan to eliminate any WAN issues.
If performance is still poor, then it's the Citrix server, the local LAN, or the app. That can be pinned down further by using the app locally. If it works fine from standard stations, then look at the LAN connection to the Citrix server and the Citrix server itself, which should have 1-2GB per remote user and no more then 20-30 users on it (I'd use task scheduler to see if it's being overworked on CPU or memory).
Also check the setup under Citrix; each user should still have their own copy of the FE by placing one in a directory mapped by account (i.e. X:\myapp.MDB, X: being different for each user).
Even with that, be aware of any references in your app that use C:\. If your using a library app in conjunction with the main app, make sure it's mapped as X:\myLib.MDB in references.
<<what they really need is a custom, .net application with a server backend that can handle what is bascially an enterprise function as users eventually will be nation-wide, then world wide and I don't even want to think about the problems that will arise under that sceanario. >>
Really depends on the number of users. If 20-30 concurrent users is it, then despite location, you should be fine with an Access/JET based app. If anything more then that, then I'd be looking at a different BE for sure.
Beyond that, switching to .Net in of itself will gain you some performance, but mainly it's a matter of developing an app in terms of client/server rather then the way most Access apps are developed.
For example, you would not bind an entire table to a form. Also things like pushing all the work server side with stored procedure and triggers, and using things like views.
So a middle of the road solution of Access FE with a SQL Server backend might be quite workable. To get an idea on that, look at some of the tips here:
The best of both worlds
http://www.jstreettech.com/cartgenie/pg_developerDownloads.asp
Jim.
ASKER
Thanks for the advice. Currently, over 250 users and that will only grow. Nothing references the local C:\ drive for the reasons you mentioned. I would love to push to procedures on a server, but our IT department simply refuses. The best they would allow us to do is hold the tables there, but all the processing code is still in the front-end. I inherited this and the one thing I hate is the fact that all the forms are bound to tables - I had a short revision time so did not change this but over the weekend, I am converting to unbound forms for the performance. Once all the data is entered, then they can hit the save button rather than having the darn thing refresh every time a line is entered - which for me seems really annoying. I am sure there will be more questions on this continuing saga.....
Sandra
Sandra
ASKER
Sandra