Allowedits doesn't seem to be working

I have a form on an access 2003 database that I want to have 'locked' by using me.allowedits = false so that the user can't accidentally change data. There is an Edit button that allows edits. I'm using this successfully on several other forms in the application but on this one form (That consists of a form / subform) the technique doesnt' seem to work.

I have set the property (allowedits) on the form itself to false. On the oncurrent event I have the following code me.allowedits = false. On the afterupdate event I have the same code. Even with all this, I can go to any field on the main form and change anything.

Can someone tell me what I'm doing wrong? Does it have to do with the form / subform?

Thanks for the assistance.


Who is Participating?
LambertHeenanConnect With a Mentor Commented:
AllowEdits has NO EFFECT if any data on the form has been altered. It may be that your form's Open or Load events are modifying something before your Current event firs to try to set AllowEdit to False
how are you setting allow edits to false? because that should stop all changes
strange just tried            ME.AllowEdits = False            didnt work

Tried                  AllowEdits = False               worked
Easily Design & Build Your Next Website

Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.

I use an Edit button too.  What I did was declare a Public variable intEditToggle as Boolean in a module(You could also pass it with OpeArgs).  I open all my forms by first setting intEditToggle to True and then DoCmd.OpenForm.  I then call ctlEdit_Button_Click from the On Open event of each form.  You might want to call it from your On Current event also.  I would play with it to suite your needs.  This worked from Access 97 to 2k3.

Private Sub ctlEdit_Button_Click()
On Error GoTo Err_ctlEdit_Button_Click

If intEditToggle Then
    intEditToggle = False
    [ctlEdit_Button].Caption = "Read Only Mode"
    [ctlEdit_Button].ForeColor = 255
    [ctlCompany].ForeColor = 255
    Me.AllowEdits = False
    Me.AllowAdditions = False
    Me.AllowDeletions = False
    [subfrmBuilderPropDetails].Locked = True
    intEditToggle = True
    [ctlEdit_Button].Caption = "Edit Mode"
    [ctlEdit_Button].ForeColor = 6723891
    [ctlCompany].ForeColor = 6723891
    Me.AllowEdits = True
    Me.AllowAdditions = True
    Me.AllowDeletions = True
    [subfrmBuilderPropDetails].Locked = False
End If


    Exit Sub

    Err_Handler Error, Err, Erl
    Resume Exit_ctlEdit_Button_Click
That is strange.  Although I have had a lot of quircky stuff happen with AllowEdits.
ME is something I try to avoid using for just such reasons.  Does ME refer to the current form?  Or does it refer to the subform if it has focus or what about when you open a subform or dialog box or open another modal dialog of anysort which takes focus?  

Try to avoid toggling properties like allowedits at runtime also. Changing some properties at runtime can also be cumbersome or unreliable.

Are you toggling the Enabled and Locked fields on the bound controls themselves?  I suspect this might override the formwide rule for allowing or not?
I have been toggling AllowEdits at runtime for many years(8 years to be exact) with no problems.  I would suspect your coding to be the cause of such problems.  Changing properties at runtime should pose no problems if your code is good.  VBA is designed to be able to do just.  Not using those features is very limiting.
Stephen_PerrettConnect With a Mentor Commented:
I didn't realise this was a problem until now!

I have played with this a bit and found that if the current record is edited in any way but not saved then AllowEdits = False fails.  If I move to a different record though it does come into play (No editing is possible).

to overcome the problem I tried

Me.AllowEdits = False

and it works reliably (as far as I can tell).

This verifies what LambertHeenan points out.

interesting. I wonder why I havn't seem this seen this in my apps?  Good for you !!!  That's why  I found that .refresh works for some and not for others. I commented it out because it only works for me.
<<I have been toggling AllowEdits at runtime for many years>>

I have seen that most people do go with bound controls.  I've most often ditched the bound controls whenever possible in favor of having complete control over what goes into the displayed unbound boxes and what gets harvested from them and inserted, updated, deleted by way of mostly SQL commands.

My two cents is,  while it is more work, the results have been far more reliable for me when I have gone this route instead.

Your point is well taken. I agree with you about unbound controls....and I agree that it does take some extra work...
w_marquardtAuthor Commented:
Thank all of you for trying to come up with the solution. The real answer came from LambertHeenan because what he explained was exactly what I was doing on the onopen event. The extra info from Steve gave me the details I needed to solve the problem. I increased the point value so splitting the points was fairer since both contributed equally to the solution.

Thanks again!

Always happy to help another Accesser.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.