ms-access – Front End Access no servidor


We normally put the Back End on the server and the Front End on the local machine.

Is there any problem (perhaps with performance) in leaving a copy of the FE on the server for each user and putting only the link for each one on the local machine?

In other words, I would have an instance of the FE on the server for each user:


And on the machine of each one of them, a link:




In practice it is quite possible, especially if users are not opening and closing the program several times. On the other hand, it is important to consider the trade-offs and certain restrictions that the application must respect (such as not saving files in the same folder as the prgorama).

My experience with network executables

Without knowing in detail how the application works, it is difficult to give an absolute answer. First I will report some bad experiences I had with a similar solution:

In a company I worked for, everyone had to use an internal system, which was accessed over the network through a link to the executable. Depending on how congested the network was, the delay in opening the program (compared to local programs) was quite noticeable. On the other hand, after the executable is opened, there is no difference in performance.

As I used this program every day, at first I tried to put shortcuts on the Start Menu and on the Desktop. However, there were often screen locks when trying to access the menu or minimizing programs to view the Desktop. This was probably because Windows was reading the executable over the network to update the shortcut icon. I say this because often the other icons were normal, except that one, and the screen was blocked until it appeared. In addition to the icon, Windows reads various information from the file for a variety of reasons. I'm tired of waiting on occasions where I was browsing directories on the network and Windows took several minutes to manage to list a few files.

After that, I removed the shortcuts and configured Task Scheduler to open the program at a scheduled time every day. However, I sometimes had issues related to security. When we accessed the directory on the server via Windows Explorer, it would sometimes ask us to re-enter the necessary credentials. In the case of the Task Scheduler, if it cannot access the program on the network, it simply did not ask for credentials and failed. Another problem is that sometimes Windows doesn't "trust" the executable and, instead of asking if you really want to open the program, it just fails silently.

Anyway, I know these are isolated cases, but it is important to consider that there are some limitations to this solution.

General considerations

Now, let me try to consider some general points:


Using executables over the network will cause a delay at startup and each time a file needs to be read. As some programs make use of configuration files, each time it is necessary to read a file the delay will repeat. On the other hand, after readings there should be no impact on performance.


Assuming that there is no problem in the network and the database server is in another location, the system will be unavailable when for some reason the files are not accessible. It's an added concern as you've added an additional node to the network to manage.


The distribution of new versions of the application will be facilitated, although in a network it is possible to carry out other forms of updating, such as via an administrative script or even an auto-update tool.

On the other hand, users will not be able to choose whether or not they want to update their systems. A new bug or an improperly published version will affect them all, every time.


If the system writes files to its own directory, this will have to be changed to write to a fixed local directory on the user station's disk or in the registry. Otherwise, each user will overwrite each other's file.

Scroll to Top