From what I'm reading, Access 2007 doesn't even support user-level security, so when I created a new .accdb file and imported objects from the old .mdb, it shouldn't have brought over the old security measures.
From what I'm reading, Access 2007 doesn't even support user-level security, so when I created a new .accdb file and imported objects from the old .mdb, it shouldn't have brought over the old security measures.
It seems like the old user-level security features from the 2003 .mdb file may still be part of the 2007 .accdb file (damn backwards compatibilitiy). Is there a removal tool?
I'm not aware of one off the top of my head. Google may help. However, if it's still possible, I think your safest bet would be to go to the mdb file, remove all the security, convert THAT into an accdb, then split the db.
The solution to your problem is like that
Copy Both Front end (Training.accdb ) And Back End (Training_be.accdb ) on a Share Drive or Map Drive in Domain where user has access
Open Front End (Training.accdb ) in open Exclusive Mode Give Password ( if You Wand) Back end should not have password
Close Front End (Training.accdb ) & repoen in share mode. Go to Data base tools > Link Table manager > Put Check mark at " Always Prompt for new location " > Select all > Click OK > In open loaction box Brouwse to your share path eg \\share folder\Training_be.accdb ( NEVER USE Local Path ) > Open Close
Give path of your front end to your user. They will get data via back end .
For security use Domain dsa.msc in server
Reply for more details
Some things to check for:
1. Make sure the form itself is editable (watch other users as they open the accdb as the only user and watch how they are editing the data - a user could simply be opening/filtering the form in a way that makes it non-editable.)
2. Make sure all users have permissions to the shared drive and folder where the accdb resides (both READ and WRITE) AND are mapping to the shared drive as the same drive letter.
3. Make sure someone isn't opening the accdb exclusively (this is where the script I posted would resolve this issue). There is a setting (not sure where it is in 2007 though) but it is set to shared or exclusive.
4. Try refreshing the linked tables in the FE. You can check the box to 'prompt for location' and point it again to the BE on the shared drive. Then have the users test. Also try refreshing to the linked tables on the user's FE on their computer to troubleshoot. Again, ALL users must have READ AND WRITE permissions to both the FE and BE. It only takes 1 user to lock others out because of insufficient permissions.
5. Make sure all users have a good connection to the drive. An unsteadily mapped drive to where the db resides could cause the *.ldb (which tracks whose in the accdb) to become corrupt and then prevent other users from opening the db.
6. Your main menu form shouldn't be bound to a table (ie. don't use the switchboard). A user who 'sits' in the main menu and has an unstable connection would then lock the *.ldb file and prevent other users from opening the accdb.
You'll need to understand that there are multiple different types of 'locking' messages. If a user cannot open the accdb at all and get's a message 'locked by another user', that's a sign that the *.ldb is corrupt/locked which usually stems back to a specific user causing the problem. The key is then to find out which user. When a specific user sits on a form that's bound to a table without doing anything, it eventually confuses the *.ldb file which tends to lock it for others to then open the accdb. Especially if the shared drive is mapped differently or has tendencies to hiccup now and then. Most often though, it's one specific user who doesn't have WRITE permissions to both the FE and BE which causes the problem (again, the script will take care of these kind of problems.)
A problem where user's cannot edit data on a specific form (but can open the accdb), is a different kind of locking problem and can be due to MSAccess settings or form design or relational structure. For this, check to see if users can edit data on any form (design a very simple form based on a single, non-relational table and test.)
I've also found problems with some users using MSAccess 2007 and others using 2003 with linked tables. For some reason, 2007 doesn't like complex relationships and making them linked tables. Especially relationships which are multi-tiered. You may also want to check for orphaned records as I don't think 2007 is as forgiving when it comes to orphaned records and (I'm guessing), causes problems with linked tables when there are orphaned records.