Could not use 'Admin'; File already in use. (1 Viewer)

I'm working on an MSAcess 2003 database and I have saved the System.mdw file to a folder on the Server and linked all users to it. When multiple users attempt to log in, they get the message

Could not use 'Admin'; filer already in use.

I have used shared system.mdw files for years with no problems. But obviously the force is not with me today.

Any help with this issue would be appreciated.

I would bet that at least one of your users does not have full file permissions to the directory that the db is located in. All users must have add/edit/delete permissions to all files within the directory that the db is located in.

Also, the db must be split with a copy of the front end installed on the users hard drive and each front end is linked to the one shared back end on the server. Each user should also have a copy of the .mdw file installed to the same directory that the front end is located. Tje front end and the workgroup .mdw file should not be shared.

You mention your .mdw file is still named as the default "system.mdw" file and that is a no no with Access security. The secured .mdw file should be named something else.

Also, the uses computers must not be "joined" to the .mdw file, you must use a custom shortcut to open the secured db with the correct .mdw file.

You might have gotten lucky with your technique before but it has caught up with you and you now have to correctly use Access security.

You need to do some searching on this forum for "security" "system.mdw" for to learn how to do Access security correctly and learn from the posters errors so that you will learn how to do Access security the right way.

I don't agree with having to move the Security Workgroup file to the local computer of every single user for one big main reason. If the admin group need to change something in the file, it should be done from a central location. By having a copy of such workgroup file on every single individual PC, such changes *WILL NOT TAKE EFFECT*. As such, it is imparative that not only is the back end file (There may be more than one of these) at a central location, but so is the security workgroup file.

However, to get around this error, it must be in a folder that has the "Modify" windows permission on the folder itself, which basically checkmarks all of the basic security options EXCEPT for the "Full Control" permission, which is NOT needed to be checkmarked to get around the issue.

Yes, the FE file face the same basic issue as the Security Workbook File as far as updates are concerned, but generally speaking, changes to a security workgroup file need to take immediate effect while updates to the FE file may not necessarily need to be updated immediately.

how are your users logging in? a shortcut? if so, what username are they logging in under?

Yes, it's still done via a shortcut with the necessary switches and other data in it. In that regards, I am in full agreement to use shortcuts for such DBs as you wouldn't want to hinder users from using other things within Access with their own projects.

As for the username, each user has their own username and password.

The basic problem is that unless you properly secure the database by using a differently named MDW than SYSTEM.MDW, there is this little "GOTCHA" that Admin in the default SYSTEM.MDW has OPEN EXCLUSIVE permission. Which, if exercised, leads to the error you have described.

Several steps are needed to properly secure an Access database to prevent this kind of activity. Search the forum for "Securing a Database" and "Workgroup Security" as topics that will lead you to some good articles on this subject.

You are right in that one should rename it to further prevent hacking, just as one should also have other things in place. However, you also have to keep in mind while there are various steps to take to help limit this, it's still a fairly weak security system. The file that I'm using does have a different file name with a meaningful name so as to help make things easier in the future should some sort of maintenance work take place.

Also, as far as the Admin user and Admins group, I first create my own set of usernames and groups, then transfer the admin rights to the newly created Administration group and the set of users who are admins of the program, then remove all the rights to the program for the admin user and admins group. Same basic thing also needs to be done with the Users group too.

One more thing, as far as the Exclusive permission that you are talking about, you need to make sure you have the database setup as being shared within the options, Advanced, Default Open Mode. I know it can still be opened in exclusive mode, but not as easily.