No need for table fields on a form

[DickyP]

But what if "controlname" refers to a non-existing control? I would only find out at runtime that it does not exist.

True but that is based on the bizarre suggestion you are going to use it for real without testing. If you do that you deserve everything you get.

 

[Isaac]

I kinda like the Me.controlname better - However, I like Dicky's method when it comes to Recordset fields.

 

[DickyP]

I actually generally use the Me.ControlName syntax - I merely offered the Me.controls("Name") as a possible choice, where necessary.

 

[Galaxiom]

But if they DO have corresponding controls and the control name is the same as the field name then Me.mumblefratz could actually be an ambiguous reference. This is why we often suggest that you should take great care to name a control and its corresponding field differently.

No ambiguity. The Controls collection is prioritised.
I use the same names and unambiguous references to make it absolutely clear in situations where I need to refer to both.

Me!Recordset.Fields.somename
Me!Controls.somename

 

[DickyP]

To me using proper naming conventions is as important as proper code formatting and proper relational data design: if you've got them you are 99% of the way to successful development.

I'm still using the Lezinski naming conventions I started using with Access2 and VB 3.

 

[The_Doc_Man]

No ambiguity. The Controls collection is prioritised.

Slight disagreement. We have seen issues on this forum in the past where the control/field ambiguity reared its ugly head. For folks who are on older versions of Access, this COULD be an issue. However, I wouldn't doubt for a minute that MSFT quietly did something about it to impose that prioritization in newer versions.

 

[MajP]

We have seen issues on this forum in the past where the control/field ambiguity reared its ugly head.

I would be interested in you or someone else citing an example, because that is untrue as far as the application. There may be "confusion" but Access is not "ambiguous" . Any issue would be purely a user issue and have nothing to do with Access. The user might be confused what they are doing but I I can ensure you it Is is not a problem with older versions of Access (at least for that last 25 years). The behavior always prioritized the control.

A user can confuse themselves and maybe think there is an Access issue.
1. You could have a control named Status that is unbound or not bound to the field called Status. That I have seen done where they renamed a control or mistakenly changed what field bound to.
2. Queries reference controls not fields so if you remove the control it does not work
3. You think you are updating the field but you are updating the control
4. Value in field can be different from value in the control until the record is saved.

Do not get me wrong, there are very good reasons to rename any control you use in code or a query. But not because there is or was "ambiguity".
I asked Chat to double check me on this.

From Access 2.0 → Access 97 → 2000 → 2003 → 2007 → 2010 → 2016 → 2019 → 365:
The rule has always been:
1. Control names
2. Field names in the form’s recordset
3. Properties/methods
So if a control and a field share the same name, Access will always resolve that name to the control first.
This is not a bug — it’s the design.

 

[DickyP]

As almost an aside the is probably no technical ambiguity -see above - but, however, there is mental ambiguity to the user in " what a I referring to this this time?"

 

[The_Doc_Man]

The user might be confused what they are doing

That, in and of itself, is a problem. If it confuses a user, it is a problem because it induces mistakes.

I'll have to try and find what the problem was, but I am absolutely certain that this topic has come up before, and I've been on the form for 25+ years. My memory isn't good enough to find it instantly, because it wasn't recent. But it was real.