X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
   Reply to this topicStart new topic
> Record Lock Settings, Access 2016    
post May 29 2018, 12:33 PM

Posts: 133
Joined: 7-February 06


I have a database application (A2016), FE & BE setup. The client uses Access Runtime 2013 (b/c of office-click conflicts with Runtime 2016).

The FE and BE are setup to have “No Locks” so that two or more users can edit the same record simultaneously. If two users attempt to save changes to the same record, they are not notified the way Microsoft.com suggests. Because it’s run in Access Runtime, the second user to save the record receives an error to the effect of “The project is protected” and then the form closes losing all edits. I have error trapping in place but it does not detect this error.

1. Would changing the database to “Edit Record” in the options alleviate this issue?
2. Do I need to make this “Edit Record” change in the options of both the fe and be?
3. And, since the client has both files as ACCDE, is it possible to make this change programmatically for the be? I have code to do this for fields and tables but have never tried to update a file’s options.

Thank you,
Go to the top of the page
post May 29 2018, 05:02 PM

UtterAccess VIP
Posts: 2,694
Joined: 12-April 07
From: Edmonton, Alberta Canada

First up, that error message don’t sound correct.

Also, keep in mind that with the runtime, if you do miss an error in some routine, then the runtime will shut down ***IF*** if you use an accDB.

If you use an accDE, then any and all errors DO NOT shut down the runtime. The other added bonus is ALL local, global vars etc. ALWAYS remain intact no matter what kind of error occurs.

What this means is even some stray “null” error in VBA will NEVER blow out the record set variable. I don’t think I need “much” in the way of explain how much more reliable your application will become if you use an accDE.

1. Would changing the database to “Edit Record” in the options alleviate this issue?
2. Do I need to make this “Edit Record” change in the options of both the fe and be?

(make this in the FE - and you have to do this for each form)

Actually, you have to be careful here. First, changing that option is ONLY the default setting used for a given form (or report).

In other words, changing locking from “no locks” to “edited” record ONLY effects when you open a table directly (which of course few do).

So this setting ONLY changes the “default” setting that you use for each new form you create. Existing forms will have pulled this default. So this locking issue is set on a form by form bases. That global setting does NOT apply to each form – each form has its own setting. (in the data tab, called “record locks”)

Ignoring your strange and incorrect error message, if you change the form locking to “edited” record, then only ONE user will be able to start editing that record. All other users will receive a “beep”, and the lock icon will show in the form (if you have the record selector enabled).

If you don’t used “edited” record, then both users can start editing the record but the 2nd (or last) user out will get the common message “this record has been changed by another user”.

If such a message is common, then I would consider setting the form to lock the “edited” record.

So the system wide settings do NOT override what you set for each form.

As noted, if possible use a compiled accDE for the front end, since any kind of error will NOT shutdown the FE, and any kind of error will NEVER re-set varaibles.

If you use a accDB, then un-handled errors not only blow out all variables, the runtime will ALSO shutdown.

Albert D. Kallal (Access MVP, 2003-2017)
Edmonton, Alberta Canada
Go to the top of the page
post May 29 2018, 07:41 PM

Posts: 133
Joined: 7-February 06


Thank you for your reply. I saw the form setting today for “record locks” and wondered. Thank you for confirming.

I unfortunately do not receive print screens from my client and only have his explanation to work with. Most of the errors the client received were “On Click” errors and the form would close or have to be closed in order to re-open and make useable. When I tested for these errors in the ACCDB version, I would see the issue. Usually it was within the code in the OnClick and had to do with NULL values. Once those were accounted for, the “On Click” errors stopped and they only received the “Protected project” error now when two people are editing the same record. I assumed that had to do with Access Runtime 2013 and the record locking selection. I will try the form setting you suggested.

Thanks again for your helpful explanation, always appreciated.

Go to the top of the page

Custom Search
RSSSearch   Top   Lo-Fi    23rd October 2018 - 05:23 AM