We help IT Professionals succeed at work.

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?
Watch Question

I'm not sure about you front-end. It's so big for 35 MB. Is there any tables in you front end?

In my past, I used to do like your way.
The speed of your database is depend on:
1. Bandwidth of your internet or intranet.
2. Number of users at the same time.
3. Size of your database.
4. Efficiency of your database.
5. Efficiency of your hardware.

There are many way to solve your problem.
1. Increase your bandwidth.
2. compact your database after logoff.
3. Change your back-end to others (SQL Server is OK for this)
4. Increase RAM for your computer.
5. Upgrade your server.

In my past. I could not touch anythings above.
Batch update and increase RAM for user's computers are my solution.
Distinguished Expert 2017
Access was designed to work on a LAN.  It is nothing short of miraculous that it also works on a WAN.  The problem is simply one of speed.  If LAN speed = 100, then WAN speed = 1 and therein lies the problem.  Converting the BE to SQL Server is unlikely to help and could even make the situation worse.  You could convert the BE to SQL Server and completely rewrite the FE to optimize it for the minimal footprint it needs to work successfully over a WAN but that is a lot of work and unless you have a really good WAN, you still might not achieve sufficient performance improvement.

The simple solution is to use Citrix or Remote Desktop.  The reason why these solutions work is because the application runs on the server and only sends pictures of the desktop over the WAN and only receives keystrokes from the user.  In fact, many clients report that using Citrix/RDS provides better performance than connecting to the database on the LAN.

Using Citrix/RDS does not require modifications to the application so you would change slightly how your version distribution works and that would be it.  It is still imperative that each user has his own personal copy of the FE and you may have to convince the admin that sets up Citrix/RDS of that if they are not familiar with configuring Access.
SQL server might work if you spent time on converting some of the queries to views, but I would find it hard to justify the time spent if you only have 3 users.
The simplest solution is likely going to be using remote desktop. Should be nearly no need for changing the database itself.
If however that is not a solution, the low-cost approach would be to start by looking at the data being pulled from the query. Something is likely causing the database to pull down all the data, or way to much data. So examine whichever query that opens in the first form, and look at whether that could be smarter. A form with many dropdowns can also be a cause of performance issues, because it takes time to load each dropdown.


Thank you a lot I will probably go with citrix solution for now.
Jim Dettman (EE MVE)President / Owner
Fellow 2019
Most Valuable Expert 2017

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.