I can go to the folder by writing \\companydomain\foldername there, but only with vpn if I am working away.
That sounds like a reasonably tight security setup in that it doesn't seem excessive but it WILL protect from anyone who doesn't know the way past the outer boundary firewall. However, your are talking about this happening even through your company's in-house network, and THAT is not likely to be based on a VPN. So it doesn't point in any particular direction.
On the windows file browser, where you write directory, it says network > [company domain] > [folder name]
That isn't how you tell about cloud sync, unfortunately. You have to look at this article and then visit the named folder to see if any of the synchronization icons are showing for the files in question.
support.microsoft.com
There are a few kinds of slowdowns that would apply to the "multiple users in the same app file" case.
1. Slow initial connection but then the operational speed would be OK.
2. Slow connection when the multiple users are doing the same thing (i.e. data entry to the same table).
3. Continuously slow operation no matter what you are doing, even when two users are looking at two different parts of the DB.
To start, you have to verify that the folder AND all files therein have proper file permissions, which must be MODIFY when using Access. Note that "MODIFY" permission is actually a category of permissions because MODIFY is like a "macro" permission... it carries over a dozen low-level permissions out of the 22 "real" file permissions. Then, all folders above your target (i.e. from the root folder of the drive to the folder where you keep the files) must have PASSTHRU permission - which lets you skip from parent folder to child folder without touching anything else in the parent folder EXCEPT the child folder.
IF your IT folks get a little crazed over all those permissions, tell them that Access will work just fine with group identifiers. (If they don't care, skip this next part.)
1. Create a "project" group identifier with a simple but relevant name.
2. Grant PASSTHRU or MODIFY permissions (as appropriate) for the group identifier in each folder and on all the files IN that folder. However, note that it is not uncommon for PASSTHRU to be assigned on ALL folders for the group "AuthenticatedUsers" - in which case you don't need to ADD the PASSTHRU permission.
3. Set the folder to let its files inherit the group permissions from the folder
4. Grant your users membership in that group.
It APPEARS that you have a short path from the host drive to the working folder, but that could be a matter of having a more complex mount point hiding the actual path. Identifying a mount point probably isn't necessary as long as permissions are OK leading to your working folder.
The problem with having a persistent connection is that if you don't, then every time you "touch" the back-end DB, you have to go through a process called "access arbitration" (little "A" on "access" in this case, meaning "file access.") If you have a persistent file connection open to the DB, then you can "ride" the connection from FE to BE without going through arbitration for each touch of the BE. A test, if you can bear to try such a thing is to open the DB and time something. Then have someone else open the DB while the first connection is still open. Do that same something, timing it - both people at once AND again, this time sequentially. Now the ugly part (as if the two-way wasn't already ugly)... Have a third person log in and do the timing tests to see how much worse it gets.
The problem is that file access arbitration over a network uses something called Distributed Lock Management, which is a scheme in which the host of a file manages that file for all users, local AND remote. When one person has a file open, it is not usually a big issue. When two or more people have a file open, they have to consult with all other locks on that file, involving extra work as they check whether any of the locks is Exclusive and/or restricts how the file can be used when someone else is using it. HINT for comparison: Share an EXCEL file. Only the first person to open it can update it. Subsequent users have it READ-ONLY while the first person is still in there.
If you have a lot of VBA code doing recordset operations, that can be an issue since in that case, record access is piecemeal, whereas if you use a lot of SQL, that is usually done wholesale and involves fewer locks. If the app that suffers a slowdown is heavily VBA based, the increased lock overhead is a good candidate for your culprit.
This random rumination might help, might confuse. But it was meant to give you some ideas of where to look.
