i am baffled as to what is happening with the database
i have a split front and back end access database
every user has their own front end
sometimes some users are able to edit the data and sometimes not. i don't know how to explain this
here are the settings:
anybody know what is going on here>?
As you can see in your screen shot, the settings are default to no locks. However, the settings in that screen are ONLY for the defaults WHEN YOU create a NEW form. In other words modifying the settings in that screen will NOT effect existing forms in your application that you've already created.
The exception to the above a course is the global setting of using row locking, that is a system-wide setting.
Again: Those options above of "no locks", "all records", and "edited record" are ONLY defaults for new forms that you create. They DO NOT change the behavior of existing forms within your application.
So you must STILL make changes on a forms by form's basis within your application, you'll find this setting in the data tab of the forms property sheet for locking behavour.
However after having said and done all of the above, I don't think that the above settings is the problem that you're experiencing.
I suspect your real problem is when an access database is opened, a separate temporary "locking" file that manages the users collisions and record locks is created (and keep in mind that this temporary locking file is created in the same directory as where the shared data is, in this case your back end shared data folder)
What this means is when users who don't have CREATE FILE permissions in that shared back end folder means access will be force to open the data file in READ ONLY mode ( if access cannot create that locking management file, then it defaults to read only mode).
What this means is when the first user who opens the database can't create that temporary separate locking file, then for the most part additional users coming into the database will also not be able to make modifications, and will also be in read only mode. This results in the perplexing troubleshooting issue of finding out that the order of what user FIRST opens the database in in a sense determined that the database will be read only.
This seems like a very strange problem indeed, but becomes far more clear once the above temporary locking file mystery is explained.
In effect, to eliminate these problems, it means that all users need file creation rights to that share folder. In fact when they exit then the last one out will cause that temporary locking file to be deleted. Therefore all uses should have file deletion rights to that share folder also.
So during your troubleshooting and testing, make sure EVERY SINGLE user has wide open file permissions to that backend folder. If you don't do this, then you will find the order of users that open that file (and those without file creation rights) will in effect determine the Read-Only status of the database.