How to Share a .MDB on a File Server
First, if you are NOT the administrator of the server where you want to house this DB, get with that person right away, up front, and discuss the requirements. I will assume we are talking Windows as the file server and not Novell or some other method. You may show this response to the Sys Admin or use it yourself as a guideline if you are the Sys Admin.
Optimally, you want to set aside a folder for this DB app that is not very deep on the drive where it is shared. Top-level is best due to the speed of the searches involved but corporate policy might require it to be second level. So, if S drive is shared, reach as S:/TKADB/TKA.MDB or at worst, S:/SharedDBs/TKADB/TKA.MDB - lower than this and management becomes a nightmare. This folder should be private in the sense that NO OTHER PROJECT should share it.
Now, the permissions. Basically, you want to create a group within your domain and allow all of the DB's users to be members of that group. Then assign permissions based on the group. The permissions you need are either (aggregate) Modify or (Detailed) Traverse/Execute, List Folder/Read Data, Read Attr, Read Ext Attr, Create Files/Write Data, Create Folders/Append Data, Write Attr, Write ExtAttr, Delete, Read Permissions.
You are unlikely to need Change Permissions, Take Ownership, Synchronize, or Delete Subfolders, but you WILL need the others because of what your users have to do with the .LDB file. The permissions should be applied to the folder and "Allow inheritance" should be checked BEFORE you populate the folder or create subfolders. If circumstances are such that you cannot make it a top-level folder, then all folders above it in the folder tree must grant "Traverse" or "List Folder" to the members of your user group. (Your corporate policy will define which of the two permissions you actually use.)
OK, populate the chosen folder with the .MDB file (or files, if this is a split FE/BE situation). Add the .WKG file. If you are using a splash screen, include the .BMP file that supports the splash. If you have related files, they can go in this folder. However, ...
If you have a lot of non-Access data files associated with this project, you have another choice. When you are talking more than a dozen or so files, you might want to isolate them. My preference is to create subfolders and put related files there. Minimize the clutter in the primary folder. If you do data exports for any reason, leave behind a sub-folder for that. If you do lots of data imports, leave behind a sub-folder for those files. (Remember to clean up import/export detritus after you are done with it.)
Side note: In Access, good housekeeping involves a few simple rules. If you open it, close it. If you are done with it, toss it. If it gets so old that you don't remember whether it is good or not, back it up to another removable medium and toss it.
If your server has a regular backup schedule, be sure that the backup operators know about this new folder that needs backing up. If not, be prepared to back up your database and support files on a regular basis.
There are various ways using VBA to locate the path to your folder. E.g. CurrentDB.Name is the fully qualified name of the DB as seen from your system. Like, S:/TKADB/TKA.MDB - and that can be parsed to extract the device and file to synthesize the required paths to the subfolders.
Now, you didn't mention it, and I won't assume it. If you want to be the administrator of the DB and let the others be simple users, you also need to search this forum for "Workgroup Security" to read over the articles on that topic. I won't re-invent that wheel right now. But that is how you would protect your data from users who can get into the DB. Windows security will not stop them because of the requirements imposed by the .LDB file - but if you implement Workgroup Security, that can and will stop them from doing a dirty deed on your DB.
The latter is an example of "not sending a cat to do a dog's job" (just to avoid sexism, age-ism, and a couple of other -isms.) Access is closest to the problem of Access security. Don't ask Windows to do from the outside what Access can do more efficiently from the inside.
