Issue:
I have two applications one desktop and one web application that interface to the same access database (I know it is not the best, but the desktop application was developed years ago and it is not possible at the moment to change).
When the dekstop app is open (and thus connected to the database), the web app fails to connect (it is developed in php and shows error 500). When, on the other hand, the desktop app is closed, everything works properly in the web app.
Question:
At this point I wonder if it is possible with an access database to have a simulated connection, and if so, if there are limits on writing or reading data.
I tried looking for information about it, but nothing that helped me.
You don't note how the connection looks, but several things are required for multi-user. first up, the server and the desktops need full rights to the folder for the database file, and this includes file create rights.
When a user (any program) opens the database, then a locking file is created. If that locking file can't be created, then the database is opened read only.
And you don't want to open the database as "exclusive" (from Access, or the web server). Again, this results in single user mode.
So, server or Access desktop better not open as exclusive.
So, we don't see the server-side connection, but from Access, when you open the database, then you see this:
So, it quite easy to open the file as "Exclusive" and that results in single user.
As noted, file create rights, and in fact delete rights to the folder should exist, since as noted, first user into the database needs to create that "locking file". Since there is no real "database server", then a locking file is created when the first user opens the database. This file is used to allow multi-user and "fake" record locking.
If such users can't create files in that folder with the database, then again, you wind up with read only, and often single user mode (since that locking file can't be created that allows multi-user operaitons).
Another issue to watch for, is when a desktop user opens the file, then the locking file is created, and often the file is created with the current user content in terms of file rights - and if such user "rights" are attached to the one user, then folder permissions for that new created locking file can often be limited to the one user - again this results in single user mode, or often read only for everyone else.
So, both systems (users and web server) require full rights to that folder, and that includes file create rights, and in most cases, even file delete rights are also required, since then when the last user exits, then the (ldb extension) locking file can be correctly removed.