When you say editor do you mean editing records as a user or making design changes to the database? Big difference between the two.

We both edit records within the database.  I am the only one making design changes.  The database has been in operation for roughly 12 years and shared (split) for the last 8 or so.  It had been working beautifully until June.  :(

I'm assuming you've tried compacting and repairing both the front and the back end databases? Every user also has their own copy of the front end right? You're not sharing the same front end accdb file.

When you try to edit a record and it doesn't let you what exactly happens? Can you post a screenshot?

I regularly compact and repair both the front end and back end databases and yes, everyone has their own copy of the front end.  It is on a network, though, and not on each person's individual computer.  I believe we tried making a copy and putting front end versions on our computers but still had issues.

Essentially whichever of us opens their copy of the database first, somehow locks it and the next person cannot edit. Forms do not have a place for the next record (like a new contact) and changes cannot be made.  The lower left corner of Access says "Records not (edited/deleted/added). Data is read-only." Additionally, if you open a table to check, no new records can be added to any tables.  If the first person closes the db, the second person can eventually edit but it takes a least several minutes as if a lock file is slow to delete, although it's not visible in the folder where that front end copy is stored.  So if I am the second person and am able to edit because she closed out, if she opens her copy up when I can edit, then she is unable to edit.  A few times she has been able to shut down AND restart her computer, reopen Access and we are both able to edit.

We have both been updated to Windows 365 and our computers have been synced with all the latest updates.  This had been working for years but all of a sudden it's broken.  I'm not aware of any change that would have taken place in our copies of the db, but I'm not an expert so easily could've done something incorrectly.  I guess that's the biggest question - could there be something in the structure of the db that's causing an issue now?

We've checked trusted locations, we've made sure we're not opening the db exclusively or read-only, we've checked our permissions on the db as well as the folder it resides in and everything seems to be correct and read/write.

Was any computer upgrade done on the PC that has the back end?  In the back end's Access options (File -> Options -> Client Settings -> Advanced), is shared mode on and record-locking off?  Create a test back end DB on that PC and see if the same problems occur.

The server where the backend resides did have some kind of upgrade - like the files were all moved from one server to a new one.  That happened in late April and this issue didn't start until early June.  The backend copy opens with shared mode and no locks on records.  I'll try a test copy (which will be on the same server) and see if we still have issues - it'll be next week when we're both back in the office.

Or you can put some test tables in your current back end, and some test forms on your current front end.  Basically, you want to eliminate as many possibilities as you can to find the culprit.  The culprit could also be a person, so don't discount the possibility of human errors.  E.g. is an idle user locking the tables?  But any number of things human do could cause problems.

Thanks!  We have 6 users total and the other four use the database rarely.  I have checked for a lock file from another user having the db open, but there never is one.

I just posted an image from last week referring to the program not being able to contact the Active Directory.  This was in the properties of the Access lock file - all permissions are checked, but I'm wondering if it can't contact the Active Directory, does it default to opening exclusively?

Anne you said, "the files were all moved from one server to a new one. "
I would talk with the "powers that be" and make sure that the folder that the back end is in is shared for everyone and also has full control for that folder.

Thanks, Scott!  I will double check to see if our IT guy checked that already.

Two additional questions - I start up Access by right clicking the icon in my taskbar, then selecting the pinned item from my list.  Could that be an issue?  Also, I close Access by closing down the tables, then clicking on the X in the upper right hand corner of the program; our IT guy found in his searches discouragement from closing Access that way and suggestions to always close the database first, then close Access by using File > Close.  Could closing be an issue?

If you can't connect to an active activity, it seems like a server issue.  You may need someone with expertise in the particular server OS you are using.  Your server's event log may also give some clues.  

The latest server OS I've used was Windows Server 2008, so I likely can't help with your OS.  We did not use Access BE on the server.  We used SQL Server, which is more robust than Access as a BE.  We didn't need to set up any folder permission, because an SQL Server database is not "a file" like an Access DB, but a "service" with a different kind of authentication and permission.

I've never had issues closing our database by just clicking on the X in the top right corner.
Our db is probably pushing 30 years old.  That being said I don't have any special events that need to fire in the closing process.
I've never had issues unless I close down while editing a record.

That's a really weird one. I've never encountered anything like that before.

My IT guy says the Active Directory message is just for additional items in Access and that if it weren't working properly we wouldn't be able to get to the Access files at all.  So I think we've ruled that message out.  I'll plan on more testing next week.  Everyone have a good, relaxing long weekend.  And stay safe in the hurricane area!!

Yeah when you've got a situation where the first person in the database is locking it for everybody else that's not right and I've never experienced that before but I'll bet someone has have you tried doing a deep Google search on this?

I've been googling and so has our IT guy.  We haven't found any solutions or even really anyone with the same experience so far.  I'm out of the office for the weekend but have a list of things to try next week.

I should say that I'm roughly an intermediate Access user but know next to nothing about general IT things and my IT guy knows very little Access, so we're kind of a mess...

I would next try what the guys suggested create a brand new database and see if the problem persists with that. If so it could be an Office problem. If not then it's a problem inside your database. And armed with that knowledge we can move forward.

Anne
I'm trying another WAG at the issue.  You mentioned that it was working then all of the sudden it didn't. That time frame seems to coincide with an update if I recall correctly.  Anyway, I also seem to remember something similar in the past where settings got changed in an update.
So if you would go check to make sure yours didn't get changed somehow.

File --> Options -->  Client Settings --> Scroll down to Advanced.
Double check that the settings didn't get switched to Exclusive in your Default Open Mode.

See pic below.

I just checked my copy and it opens in shared mode.  My co-worker has checked hers in the past and that's  been true for her as well but I can have her check again tomorrow.  I noticed that my copy doesn't have the box checked for record-level locking.  Would that add to the problem?  What we had found talked about locking records could cause issues.  And we haven't gone in and changed any of these from the defaults and definitely not in early June.  But I'm happy to explore any and all options - just want to solve the problem!!  Thanks!

Shoot I was hoping that would be the culprit.

I don't know about the others but I'm afraid I'm out of ideas.
The only thing I can suggest is to take one of Richard's free templates and split it.  Put the BE where your current BE is and put the FE where your current FE is.
See if you have  the same issues.  If you don't that would point to something being amiss with your current db files.
If you have the same issues with the template file, that to me would point to a network / file sharing issue.

You could, assuming that your network allows it, also share a directory directly on your computer.  Same thing.  Put the BE there and give the FE to your colleague.  Again that would point to network permissions.

I'm sorry you are having issues!  I've been down that road and I feel your pain.

You definitely want record locking on. The alternative is table level locking in which it will lock the entire table.

If you turn off the option for record-level locking, it means that Access will use table-level locking instead. In record-level locking, only the specific records that are being edited are locked, allowing other users to edit different records simultaneously. However, if you disable record-level locking, Access will use table-level locking, which locks the entire table when any user is editing it. This can prevent multiple users from making simultaneous edits to any records in that table. Keep in mind that table-level locking can impact performance in multi-user environments, as it can lead to contention for access to the entire table.

Record Locks

EVERYONE that is using this database needs to have record level locking set to on otherwise when that person opens the database they'll lock the entire table.

Working on setting record level locking on all my zillions of forms.  After reviewing the Record Locks video, I had an idea so we checked a couple things.  Typically my co-worker is editing tables A, X, Y and Z, where I am editing tables B, C and D, but a lot of those things are all tied to Table A.  So while I was in and had editing rights, I opened a form that would include information from Tables A, B, C and D.  I asked my co-worker specifically to open tables X, Y and Z to see if she could edit them.  I wouldn't have (or shouldn't have) had any locks on tables X, Y and Z, but she still didn't have any editing rights for anything.  So at least we ruled one more thing out.

If at all possible try to design your forms with as few tables as possible. I like opening additional forms that are based on different tables for example if you're working with a customer data try to have the customer for him have just customer data in it and then if you want to see contacts or orders click a button open up that form. This way you have as few tables open as possible in the background. Sure occasionally you'll use a subform or two but try not to base your forms on four different tables because then you run into lock issues like this sometimes.

Thanks, Richard!  That's kind of what I'm trying to determine - if it's a db structure issue or something else.  We've been using the same forms for many years so it seems odd that it would be form related all of a sudden.  That said, we are constantly fine-tuning them based on workflow so perhaps something was adjusted that tipped the scales.  :(

I found out some additional information this morning.  In our db, we have tables linked to three different backend Access databases, each one housing unique information.  We ran into editing issues again so each time I'm trying to troubleshoot.  This time I had gotten into the db first and done some editing, then closed all the forms down.  My co-worker got in after me but she was able to edit things because by the time she opened her copy, I didn't have anything open - no forms, tables, etc.  So I checked to see if I could open anything and edit and decided to look at every table, item by item.  The pattern I found was that any linked table from our main db is locked and I cannot edit.  Anything coming from either of the other two backend db are available for editing.  So that seems to eliminate the network concerns or all tables would not be editable.  And that means the issue must be with the main backend copy.  So I'll focus testing that theory.

Today's update.  I created copies of my front end and back end, emptied things, reloaded data and relinked tables in the front end.  Same issue with editing.  I've gone through Beginner Level 1 and started Beginner Level 2 and I have a couple of questions about our original structure.  1) I used the Lookup Wizard in fields where I wanted to pull information from a different table.  I see they're evil.  Could that be part of the problem?  2) My emails are hyperlinks, also frowned upon.  3) Relationships have been identified/established in the database Relationships tool.  Would that cause issues?  Maybe during original construction there were enough bad choices made that it's tanked the db now.  It just is still confusing how it could work for roughly 8-10 years with no issues but now crashes - that makes it feel like it's not the structure.

I'm going to switch gears and test a baby db with just a little data in it and see if we run into the same problem.

Update for 9/20 - I created a new blank database.  I replicated (did NOT import) a small number of tables from our main db.  This does include lookup language in several fields, so a possibility?  I also replicated (again, did NOT import) two or three queries and two reports.  Once those were all in, I split the database and made a copy of the front end version to put in my co-worker's folder.  So, should be fresh material other than temporarily bringing in one of the old db tables and appending the data to the new table.  Fresh split, no macros or anything else, very, very minimal information.  When she and I tested this today, we had the same lock issue as we do with the main db.

Next will be creating an entirely new db from scratch, different material, completely unrelated, splitting and testing that one.  Wish me luck!

Are all the problematic back end files stored on just one computer, all this time?   If so, try storing them on another computer and see if you still have lock issues.

Kevin - I'm having my IT guy check to see if we have options for testing the server.  I've used the TechHelp Blank template for a couple tries - one with brand new tables and data and one with replicated (not imported) tables and appended data and both end up with the same lock issue.

Just use any regular Windows PC on the network (if you haven't done so already) to store the problematic back-end file and see if it works.

Have you performed an office update lately? I know that they were having record locking problems in an Access version not too long ago that was fixed by a recent bug release.

We had gotten both our computers updated with all the Microsoft items recently and our IT guy made sure that our computers matched.  That didn't resolve anything.  It actually sounds like when our files were moved to the new server, it was cloud-based, and others have experienced being locked out of their files (NOT Access files) so they will be moving things back.  I suspect that's the issue as Access is clear that it doesn't work if the files are cloud-based.  I will report back if that move resolves our issue!  I'm optimistic but have no idea when it will actually happen.  :)

It just seems you need better IT people to get a handle of the situation.  If they don't know what's going on, they can't tell you, and you can't tell us.  And we here can't help you if we aren't clear what's going on.  You seem like a good describer, but that would be no use if you were given bad or false info by your IT.  You need better people to go on site and fix this.  It could be a simple thing after all, but you and we wouldn't know that with this cloud of uncertainty over us.  Two months is a long time to have this kind of problem go unfixed.

Yeah, if you're an IT person who moved your Access database to a cloud drive, then that's definitely the cause of your problem. I've said this in many different videos: you can't run Access over a cloud setup unless it's something like SQL server or SharePoint. And in those cases, it has to be specifically set up for those environments. You can't just put a back-end Access file on a web server and expect it to work. You may have IT guys who are good at generic IT or networking or PC setup and repair, but unless they're specialists in Access, then they might not know what they're doing in regards to that. A lot of people turn up their noses at Access because they think it's not a real database setup, and I hate those people.

It appears that our problems have been resolved by moving the files back to a physical server from the cloud.  Had I known they moved them, I would have started there!!  To be clear, we do have good IT people, it's just that we are an extremely large organization and it's probably impossible for them to know all the things that are being done throughout.  That said, it seems like it would be easy enough to send a mass email out when something like this is planned so that anyone with concerns can speak up.  It sounds like moving to cloud storage caused similar lock problems for others and I'm just thankful that our issues seem to have been resolved now!!!  Thank you to everyone who provided input.  I very much appreciate your support (even though this kind of turned out to be a no-brainer...)  Anne

This seems like a situation that is a recipe for disaster.  If your IT people (a) moved things without telling you, (b) without knowing whether they should or not, then they are not good IT people.  If I caused *three months* of lost connection because I had ordered IT people to do this, I would be "going away" for a while, along with my IT people.