asked on MS Access Front End -Back End design
I know that MS Access is meant to be database for personal use on user desktop, laptop or eventually shared and used in LAN environment for not large number of users.
However, I have inherited a MS access 2010 database split on Main_Front_End and Main_Back_End. Main_Front_End is around 35MB size Main_Back_End is around 100MB.
All forms on Main_Front_End are bound to back and tables.
Main_Back_End database is located in server share folder and copies of Main_Front_End are on users local machine. There are 3- 5 users.
Problem is speed and efficiency. Company has main location in one City and offices in several other Cities across country. Users using this database in main location, sometimes in other City company office locations and sometimes accessing database from home over VPN.
Users are complaining that sometimes it takes 15-30 sec. for start form to open when they accessing this from other location and from home.
I need some advice what can be done to improve speed in current settings and database design. And advice how it would be the best to adjust and make correction in database design.
I assume first option would be putting Main_Back_End on SQL Server database and link Main_Front_End to tables on server database thorough DNS-Less connection. Not sure will it improve speed if forms are not bound?
What do you suggest as option to create Main_Front_End in VB.Net or other language and make more robust application?
However, I have inherited a MS access 2010 database split on Main_Front_End and Main_Back_End. Main_Front_End is around 35MB size Main_Back_End is around 100MB.
All forms on Main_Front_End are bound to back and tables.
Main_Back_End database is located in server share folder and copies of Main_Front_End are on users local machine. There are 3- 5 users.
Problem is speed and efficiency. Company has main location in one City and offices in several other Cities across country. Users using this database in main location, sometimes in other City company office locations and sometimes accessing database from home over VPN.
Users are complaining that sometimes it takes 15-30 sec. for start form to open when they accessing this from other location and from home.
I need some advice what can be done to improve speed in current settings and database design. And advice how it would be the best to adjust and make correction in database design.
I assume first option would be putting Main_Back_End on SQL Server database and link Main_Front_End to tables on server database thorough DNS-Less connection. Not sure will it improve speed if forms are not bound?
What do you suggest as option to create Main_Front_End in VB.Net or other language and make more robust application?
DatabasesMicrosoft AccessDesktops
Last Comment
Jim Dettman (EE MVE)
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Thank you a lot I will probably go with citrix solution for now.
Just to add a couple of comments:
a. Going RDP/Citrix is absolutly the way to go for this situation.
b. The biggest thing that kills Access over a WAN is network latency. While speed is a big factor from a user perspective, it's not the show stopper. As a matter of just plain working it's the latency. Access with a JET/ACE database, wants <30ms. If it doesn't get that, then you start having all kinds of problems and corruption. Even in a LAN setting with wireless connections, you can have problems because even though the speed is there, there can be too much latency. Likewise, some high end WAN's do work and work fine (it is rare to find these though - they are generally fiber optic point to point connections).
c. Converting to SQL would help, but not as much as one might think unless you take advantage of the features as Ander's said. For this type of situation (remote users over the internet), it usually means a total re-write of the app and at that point, you might as well use something else.
RDP/Citrix is the ticket, and as Pat said, it's basically plug and play. There are very few changes you need to make usually. Biggest thing is apps that create temp files. Keep in mind that in a RDP setup, all users have the same drives, so if your app creates temp files, they can clash. Usually an easy fix though.
Jim.
a. Going RDP/Citrix is absolutly the way to go for this situation.
b. The biggest thing that kills Access over a WAN is network latency. While speed is a big factor from a user perspective, it's not the show stopper. As a matter of just plain working it's the latency. Access with a JET/ACE database, wants <30ms. If it doesn't get that, then you start having all kinds of problems and corruption. Even in a LAN setting with wireless connections, you can have problems because even though the speed is there, there can be too much latency. Likewise, some high end WAN's do work and work fine (it is rare to find these though - they are generally fiber optic point to point connections).
c. Converting to SQL would help, but not as much as one might think unless you take advantage of the features as Ander's said. For this type of situation (remote users over the internet), it usually means a total re-write of the app and at that point, you might as well use something else.
RDP/Citrix is the ticket, and as Pat said, it's basically plug and play. There are very few changes you need to make usually. Biggest thing is apps that create temp files. Keep in mind that in a RDP setup, all users have the same drives, so if your app creates temp files, they can clash. Usually an easy fix though.
Jim.