Front End Access on the server

Question

Usually we put the Back End on the server and the Front End on the local machine.

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

That is, I would have on the server an instance of FE for each user:

FE_Joao.accdb
FE_Pedro.accdb
FE_Maria.accdb

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

FE_Joao_atalho
FE_Pedro_atalho
FE_Maria_atalho

Answer 1

TL;DR

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

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 where I worked everyone had to use an internal system, which was accessed by the network through a link to the executable. Depending on how congested the network was, the delay to open the program (relative to local programs) was quite noticeable. On the other hand, after the executable is opened, there is no performance difference.

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

After that, I removed the shortcuts and set up the Task Scheduler to open the program at a scheduled time every day. Meanwhile, I’ve had some security issues. When we accessed the directory on the server via Windows Explorer, it sometimes asked us to re-enter the necessary credentials. In the case of the Task Scheduler, if he could not access the program on the network, he 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 simply fails silently.

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

General considerations

Now, I will try to consider some general points:

Performance

Using executables on the network will cause a delay on startup and each time it is necessary to read a file. 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.

Availability

Assuming there is no problem on 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 a further concern as you added an additional node to the network to manage.

Distribution

The distribution of new versions of the application will be facilitated, although in a network it is possible to perform other ways 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 to update their systems. A bug new or an improperly published version will affect all of them, always.

Competition

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’s station disk or log. Otherwise, each user will overwrite the other’s file.