We work with a large Access database and we want a few users (max. 5 to 6 at the worst) to be able to edit tables at the same time by using forms. We have split the database into front end and back end. The BE is placed on a NAS and each user has an offline copy of the FE on his own desktop.
All users have full permissions and we switched the options (client settings -> Advanced) to the following settings:
Default open mode: Shared
Default record locking: Edited record
Open databases by using record-level locking: yes
Encryption method: use legacy encryption (good for multi-user databases).
In the forms we also changed the property ‘record locks’ to ‘edited record’.
What we want to achieve is that when a user change a certain record in a form, other users can’t change the same record until the changes of the first user are saved. We also want to see a lock icon in the selector bar, as mentioned in this forum:
Instantly "locking" a record in multi-user Access environment
For the moment we have done several tests, but we are unable to generate any “Writing conflict” when implementing the above, contrary to the numerous reports on the opposite behaviour one can find reported in the internet and the documentation of Access. The first user changes a record and the second user is still able to change it, without any particular notification in the sense of a selector bar icon or a “writing conflict”, and the user that closes the database the latest takes it all (all changes by the first user are overruled).
Can anyone explain me what we are doing wrong.
You have to set the locking on a form by form basis. So changing the client settings to "edited" record will ONLY become the default for new forms you create.
So, to set locking for a form to edited record, you MUST set EACH form you have to Edited record. Once you do this, then additional users attempting to edit the same reocrd will see + receive a lock icon in the selector bar. They only will see this bar WHEN they attempt to start editing, but if you set form to "edited" record, then this should work fine.
The "over all" settings you are playing with don't change anything here (well except the option to open databases as shared - but that's already the default and already a given since more then one user is able to edit the data.
So change the form in question locking setting to "edited" record. You now have record locking setup for that one form. Settings for record locking are a form by form setting - the other settings really don't matter.
Related
Im using msaccess 2010 on Windows 7 and faced the following problem: in multiuser mode editind ALL of record and adding new record blocked in all forms when some user working with database, in single user mode all work perfect.
Database is separated to front-end and back-end parts. Back-end part is located on network drive in directory with full right for all users, copies of front-end part are on users computers.
In client settings: Default open mode - shared, Default record locking - no lock, open database by record-level locking -on
In forms properties - allow add, edit, delete - yes, block records - no.
What could be the problem?
In most cases, this should just work.
Several things to check.
first up, the shared folder where the data part exists needs FULL rights. That means create file rights, and delete file rights. When a access database is opened, then it creates a 2nd file in that same back end folder. That 2nd file is how access handles and manages multi-user operations. If users dont' have create file rights, and delete file rights to that folder, then that mutli-user locking file cannot be created, and thus in most cases, the result is a read-only database.
Next up, do check your forms. You do NOT want the settings to lock the WHOLE table. That is this setting:
So, if you set above to "all records", then of course only one user can edit that table the form is based on.
That setting is a per form by form basis, and thus you do NOT have a global wide setting for this. And you should ALSO check reports - they should have all no reocrds, since you can lock a whole table for some speical reports - and in 99% of cases, you don't need nor want that.
but, check the shared folder rights. the users need read/write AND ALSO file create, and file delete rights. If they don't have such rights to that folder, then in most cases you find the result is a read only database.
I'm fairly new to Access and am struggling with setting a pessimistic Record Locks policy (Edited Record). I have a database that I am developing and have not published yet, so it is not split at the moment but will be in its final form. I have a few tables that will be accessed through forms by multiple users at the same time, and ideally I would want the Record Locks property of these forms to be set as Edited Record on a row basis so that once a user starts editing one record, other users cannot mess with it but can still edit all the other records. I have:
set the relevant forms' Record Locks property as Edited Record
enabled the "Open Databases by using record-level locking" advanced option
read/write permissions to the folder where the database is
..but it is not working correctly. It seems that Access is still locking records at the page level, as I am prevented from simultaneously editing two adjacent or "close" (within 30 rows of each other or so) records.
I even tried creating a brand new database, just one table and two forms (actually one form duplicated with two different names) - result is the same, once I start editing one row of data in one form, all "nearby" rows are locked from editing as well. I tried splitting the database, asked another user to try on his machine together with me, but always the same result. What am I possibly getting wrong?
I have no issue sharing the brand new database I made as a test if needed, not sure where I can upload it though.
Ok, a few things:
Given this is not split? Ok, less things to check.
so, you have this setting:
and for the test form in question, you have this:
Now, we assume you not left out some huge-massive whopper here, right?
First up - we assume no one else, or no other program has this file open.
we assume that you do NOT have ANY startup code at all - but are just launching to that form? Right (if you have startup code - especially ANY code that opens the database or opens a table? ALL BETS ARE OFF!
next up: since this is a single user machine - I would re-boot - just to ensure that no stray copes of Access are running or were left running due to all this testing.
Note that the FORM MUST open the table(s) in question. There is NOT to be ANY code of ANY kind that runs before the Access UI application say via form OPENS that table.
The above is BEYOND important!!!
Why?
Because DAO code, VB code or ANY OTHER PROGRAM or PROCESS that opens the file BEFORE YOUR access applicaton does? Then you not get row locking.
And the above tip ALSO includes ANY VBA + DAO code!!!
You see, the JET (now ACE) row locking feature? There is ONLY one way and ONE WAY ALONE to use this feature:
It ONLY works from the MS-Access UI. That means no VBA code can do this, no vb.net code or ANY OTHER system or code can run before Access UI (forms) opens a single table.
The reason why?
The first person + process WILL determine if the row locking feature is turned on. And I want to double, tripe, quadruple and MORE stress that ONLY the UI can cause the ACE/JET data engine to engage this row locking feature.
In other words:
If on application startup ANY CODE that runs that opens a table (DAO or ADO code) then that code who FIRST opens the database will from that point on force ALL OTHER programs, forms and yes even MS-Access forms to NOT USE row locking. (you get page locking).
So, this is a first in kind of setting.
the FIRST process that causes a table to open will then determine if row locking is to be turned on. And the ONLY POSSBILE WAY for this to occur is if the MS-Access UI opens a table (any table) with a form. You cannot have ANY code run that touches a table BEFORE that UI opens a table. So any kind of say startup code, or even code (rather common) to create a persistent connection will thus ignore the row locking feature.
And if any other outside program, say ODBC from FoxPro, or even code in vb.net, c# etc. opens the database BEFORE the Access UI gets it hands on the table(s)? Then once again, row locking is not used (page locking of course will be used).
So the flip, the flag, the switch to row locking CAN NOT BE set in code. (you can set the options in access via code - but then you get that prompt about having to restart access (and you must do so if you change that row lock feature). So, code can change the setting, but it will NEVER take effect until you re-start. And thus once again, code cannot set this on startup (only change the settings that tells access what to do on startup - and it too late to thus change it in code once code starts running.
So, just keep in mind that you need as the first thing to launch is some form that is bound to a table, and that form will have to run first before any DAO or any other kind of VBA code grabs or opens a table via DAO or ADO code.
If code uses the DAO/ADO object model, then you by-passing the Access UI and thus no means to tell JET/ACE to use row locking. This is a MS-Access feature and NOT a JET/ACE data engine feature. As a result, you have to ensure that it is the Access UI that opens that table. Once that has occurred, then any and all other code, forms and even external ODBC connections will now respect the row locking feature.
I have an Access 2013 DB with 2 subforms: The first one provides current data and the second one I'm trying to set up as a sandbox space for users to make changes and updates at their leisure. When they are ready to submit those changes and updates they can hit submit and their results will update the current data and table info behind it.
Been a while since I've messed with Access so I can't recall if this can be done so thought I would ask.
It can’t be done without a rather messy approach. Forms in access ALWAYS edit ONE row.
What I do in these cases is allow the user to “edit” as much as they please.
However, say we are doing a “classic” check or donation amount enter. So you have a donation amount (say $50), but you THEN have to distributed the amounts to various donation accounts.
With the above, you don’t want to save the data until such time that the amounts distributed to accounts match the donation amount.
Because we can’t contain the form + sub form as a “single” update, then what I do is add a posting flag to the parent form (the one record in the main form).
The user can then edit/add, go away for coffee, and come back and edit some more. You can even come back the next day and continue editing.
Once the user is happy, then you have a post button on the form.
If the user hits post, and the balance amounts don’t match, then you don’t set the postOK flag = true.
The above will thus NOT provide a means for the user to bail out, or un-do their edits to the “whole thing”, but it does allow you to determine that the data entered has been “balanced” and verified. And if the “balance” did not occur, then you can skip that record, or introduce a process in which the data is not posted or marked as done until such time that the data balances.
Here is a screen shot in Access of a “classic” money distribution to several accounts. You can see the donation amount on the left side, and on the right side is the account distribution of that amount.
However, at the bottom of the screen, for the “job task” the user is working on also has a post button. When they hit the post button, if the amounts don’t balance out, then the posting is NOT yet done. In fact, I let the user enter "many" donations, and then they can "post" all at once for ease and speed of working. The "post" does NOT actually post, but checks the balance. So users "think" they are posting, but it only really ever sets one value (a flag POSTOK).
So to run a report, it can’t be run until such time that the post button was hit.
As noted, this approach will NOT give you a “bail out” option to exit your data entry, nor does it allow you to “undo” the data entry, but it DOES allow you to verify the posting is “ok”, and “valid”. In many cases this approach will suffice.
However, if you looking for some kind of “undo” for the form + sub form edit, then Access quite much is not the correct tool for that type of business model and edit.
I would suggest you set up a local temp table for the sandbox.
Then when you say 'When they are ready to submit those changes and updates they can hit submit and their results will update the current data and table info behind it.' ….. instead what happens is the Sandbox Temp table record appends or inserts/updates the actual table.
If this is a split multi user app and the Sandbox temp table is local - then the data is indeed temporary and the update must occur within the user's session. But the overall design is quite simple.
After finally getting back into this I realized I was looking at Access development through the eyes of how I would do it in Excel; both different ecosystems. I took off my Excel forms dev lens and a few things occurred to me that I think may help others with similar struggles:
Access and Excel are different VBA development ecosystems. You can’t necessarily code it in Excel and expect it to work flawlessly in Access.
A subform is just a form...and like all forms its controls, code, and behavior don’t change in functionality but in presentation based on form type (datasheet, continuous, etc).
Treat each Form and event code independently of each other. If your subform on a parent requires events to kick off when a user adds, updates, deletes, validates, etc. that code should belong in the form that makes up the subform.....not the parent.
The parent form should only control filtering and results from the subform as well as it’s own set of actions the user has.
The Screen method is amazing and one I think would have saved my life for tracking changes. Great link here: https://www.datawright.com.au/access_resources/tracking_data_changes_in_access.htm
There are two cases where Access autosaves changes:
When the user enters data into a form, this data is autosaved to the linked table
When the form developer modifies a query, form design view, table definition, etc. these changes are autosaved after exiting the editor
I'd like to know how to change the second point so that Access only saves the file if I hit CTRL+S, similar to Word and Excel.
Though Access does ask if I want to save changes when I exit (for example) the form design view, the only way to test changes is to exit design view, which saves the file and clears the undo button. It can be very inconvenient because I have to undo everything manually if I want to revert changes.
I've found threads discussing older versions of Access, but nothing for Access 2013. Is there a way to do this?
Forms, Reports, and Queries can be tested without saving - just switch view.
Tables cannot. If you wish to check out design changes, first create a backup of the database or at least the table.
I've been handed a problematic Access 2007 data base solution. The problem to start with is in avoiding record locks the original designer decided to split the data into three separate data bases (based on product line) which would avoid one program manager locking out another. The second problem now is that if anyone opens any one of the three data bases, they lock out the writers who can only open in read access.
There are approximately 100 users globally with three or four writers, the rest being readers. The data bases are on a SharePoint site.
To solve the issues, I'm proposing to do the following based on research to date.
1) Create a split data base thereby isolating the front end user interfaces from the data repository.
2) Create two front end interphase databases connecting to the backend. One is for readers, the other for writers.
3) For the readers, I'll be adding the following code to each form's Form_Load event:
Me.AllowEdits = False
Me.DataEntry = False
Me.RecordLocks = 0 ' No Locks
This seems to work (in the limited testing that I can perform) in that it allows the readers to change column widths etc., copy from and paste elsewhere data but prevents them from locking the records for the writers and/or making any changes to the data.
4) For the writers the following to the same On-Load event:
Me.AllowEdits = False
Me.DataEntry = True
Me.RecordLocks = 2 ' Edited Record
This works in preventing writers from saving changes to the form but allows editing of disparate records (although Access help says RecordLocks applies to the Page of records which sounds like they are talking about the table, not individual records??? My tests seems to show exclusivity to the record a writer is editing, not the entire table.).
5) I'm going to move all the records from the three data bases into one as the original work-around to avoiding record locks seems to have been resolved through the above steps(??). I should point out that the likelihood of one writer editing a record that is owned by another writer is very low. However, a writer editing a record cannot lock out another from editing a different record in the same table.
So far so good I'm thinking.
The next plan is to place the data base (Front and Back) on SharePoint. However, all the research I've seen indicates that each user should get their own front end locally. I would like to avoid that for obvious reasons (updating multiple Front Ends established on local machines). So my questions here are as follows:
A) Will SharePoint's own permission levels interfere with those set internally in the Access data bases? Right now, anyone (readers and writers) can edit a record.
B) Why can't I place the two instances of the Front Ends that multiple users can share? In other words, if the users are only reading or writing, can they not use/share the single instance of the Access Front End without locking if from use by other users? Right now, anyone can open the data base from the SharePoint site. It's just that the first one to open it gets write access. Everyone else who try to use the same data base are set to read only including the writers (but this is resolved first of all through splitting the data base, no?).
Lastly, if the SharePoint thing is a non-starter for any reason, I can use a shared network folder.
Any thoughts would be appreciated. Thanks
Seeing as there is no answer forthcoming to my query here, I'll answer myself with research and tests I've conducted.
First of all, using VBA to manage form properties and controlling the Writer's front end from being accessed by a non-authorized reader is a fail. When Office is loaded onto a user's workstation, the macro setting is defaulted to "High", or "Do not run Content...". So when a Reader inadvertently opens a Writer front end, the Form_Load event is blocked from running and the user has full edit permissions. If they happen to allow the macro to run, then the proper settings are established but it is assumed that most will not click on the "Allow Content to run" button. The solution then is to set the permissions in the form's property sheet. Yes a determined user can hack through if they want but who wants to do someone else's job in editing records.
The settings for the reader are as follows:
Data Entry: No
Allow Additions: No
Allow Deletions: No
Allow Edits: No
Allow Filters: Yes
Record Locks: No Locks
For the Writer:
Data Entry: No
Allow Additions: Yes
Allow Deletions: Yes
Allow Edits: Yes
Allow Filters: Yes
Record Locks: Edited record
I noted that when the Data Entry property was set to Yes, then the MS Find became unavailable. It's used to get to a particular record. Don't know why it becomes unavailable but there you have it.
The same applies to controlling access through a IsValidUser() function. The solution for the Writer front end is to password protect it. Again, not 100% fool proof but enough to dissuade an overworked engineer from going any further.
Putting the back end data tables onto SharePoint is not an option. You can't link any of the front end objects (Forms, queries etc.) to the underlying tables if they are on SharePoint. You can send the tables over as a list and then link to that but I was getting all manner of "Invalid path..." errors when I tried to update the links. So the back end resides in a standard Windows network folder.
There is no reason why you can't have a single Access front end residing on SharePoint that can be accessed concurrently by multiple users to view or edit records. Setting the Writer form's Record Lock property to Edited Record (aka Pessimistic) locks out a writer from editing a record already being edited by someone else. However, they can edit another record. On the Reader side, it is set to No Locks. This all works.