developingprogrammer
asked on
problems with changing recordset of form
hi guys!
recently Christian (Bitsqueezer) was helping me out with a question and he shared this portion with me below
so i also did some reading up and came across this on FMS's website (http://blog.fmsinc.com/microsoft-access-inconsistent-compile-error-for-a-field-reference-in-a-form/)
really good stuff there.
so i just wanted to ask yall and also Christian in this question, what are the problems that yall have faced using a parameterised query as a form's recordset?
thanks so much guys!! = ))
recently Christian (Bitsqueezer) was helping me out with a question and he shared this portion with me below
But be careful: A parameterized query assigned through the Recordset property sometimes can be a little bit strange, depending on the query, the fields in the form, the functions you implemented. It needs more tests than a normal bound query.
so i also did some reading up and came across this on FMS's website (http://blog.fmsinc.com/microsoft-access-inconsistent-compile-error-for-a-field-reference-in-a-form/)
really good stuff there.
so i just wanted to ask yall and also Christian in this question, what are the problems that yall have faced using a parameterised query as a form's recordset?
thanks so much guys!! = ))
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi
You seem to have taken this a bit personally (judging by caps use) - I was looking to avoid that and I don't want to end up trying to hamer this home.
However, since you ask...
You stand by the absolute position that the Bang is not to be used at all.
The single rationale for this seems to be that the compiler doesn't check it for validity.
That's all? (Besides the compiler, I find testing my code/forms works rather well in determining any incorrectly referenced fields/controls.)
My example of:
Me.Recordset.Fields("Field
will also not be checked by the compiler in exactly the same way.
(Though it's worth noting that they're refering to different objects.)
The example of a variable, well I don't think it's fair to assume that a variable for the field names would be held.
And of course, you'd not try to use Bang with one of those. You're stating the point as if we were saying Bang is the only method to achieve anything.
The dot wouldn't alow you to use a variable any better.
Me.VariableName doesn't get you anywhere. You have to use the collection then (see later for more on that).
FWIW - yes I use dot a majority of the time. (I'm not trying to say that Bang is the be all and end all.) But I absolutely maintain that this is not a case for a dogmatic insistence that a certain method be avoided.
Yes, what we give here is opinion. But backed up with facts makes the difference.
Comments like
What can't be refuted is simple fact:
Me!FieldName
is syntactically identical to
Me.Controls("FieldName")
by Access. (That used to be a recommended way of referring to controls actually at one point - but again, that's a suggested preference for a reason - not an absolute.)
The controls collection in this instance includes the vitual controls that are AccessField objects. (You'll not see it in the Count or if you iterate the collection - but it's returned by name. Much like instantiated forms in the forms collection.)
The AccessField object is then available (without many of the standard control or field properties - but available none the less).
It's just an object. Not the devil. Deciding when it's OK to use it and when not is part of being a developer. (And changing source forms is absolutely No. 1 on the list of when to.)
You mention citing a time when to use it? Why use the recordset instead? It's a longer, more involved, less efficient expression.
I'm just saying - this is not a hard and fast rule occasion.
It's not like we're talking about normalisation, splitting FE/BE etc.
Cheers.
You seem to have taken this a bit personally (judging by caps use) - I was looking to avoid that and I don't want to end up trying to hamer this home.
However, since you ask...
You stand by the absolute position that the Bang is not to be used at all.
The single rationale for this seems to be that the compiler doesn't check it for validity.
That's all? (Besides the compiler, I find testing my code/forms works rather well in determining any incorrectly referenced fields/controls.)
My example of:
Me.Recordset.Fields("Field
will also not be checked by the compiler in exactly the same way.
(Though it's worth noting that they're refering to different objects.)
The example of a variable, well I don't think it's fair to assume that a variable for the field names would be held.
And of course, you'd not try to use Bang with one of those. You're stating the point as if we were saying Bang is the only method to achieve anything.
The dot wouldn't alow you to use a variable any better.
Me.VariableName doesn't get you anywhere. You have to use the collection then (see later for more on that).
FWIW - yes I use dot a majority of the time. (I'm not trying to say that Bang is the be all and end all.) But I absolutely maintain that this is not a case for a dogmatic insistence that a certain method be avoided.
Yes, what we give here is opinion. But backed up with facts makes the difference.
Comments like
... and normally you can be sure that the control name has the priority when Access searches the name. But "normally" is not enough, sometimes Access finds the field name property before the control nameare anacdotal at best. That would imply a major failing in Access (i.e. a bug) and should have been raised with MS (assuming it was reproducable and not attributable to something elsle.)
What can't be refuted is simple fact:
Me!FieldName
is syntactically identical to
Me.Controls("FieldName")
by Access. (That used to be a recommended way of referring to controls actually at one point - but again, that's a suggested preference for a reason - not an absolute.)
The controls collection in this instance includes the vitual controls that are AccessField objects. (You'll not see it in the Count or if you iterate the collection - but it's returned by name. Much like instantiated forms in the forms collection.)
The AccessField object is then available (without many of the standard control or field properties - but available none the less).
It's just an object. Not the devil. Deciding when it's OK to use it and when not is part of being a developer. (And changing source forms is absolutely No. 1 on the list of when to.)
You mention citing a time when to use it? Why use the recordset instead? It's a longer, more involved, less efficient expression.
I'm just saying - this is not a hard and fast rule occasion.
It's not like we're talking about normalisation, splitting FE/BE etc.
Cheers.
Hi LPurvis,
no, no, that big letter writing was not ment to be anything personal, it was only ment as accentuation, maybe I should write such things in italic letters or anything like that - sorry. It is really sometimes difficult to write something in a way that others understand the way it was meant to be understood, that's a problem in all written communication.
Be sure that I don't take anything here personal, in the same way I do not want to affront someone with what I write.
You are of course right in comparing the statements about using a variable with the dot is also not possible and you are also right that the compiler can also not test the value if you use a literal as index in a collection. In that case I always use a constant so the compiler can at least check the constant - and I only need to check the value of the constant once, but can use it as often as I want. That's another "must have" I try to not forget that whenever I use literals, always working with constants, variables or values coming from a settings table.
You're also right that using a collection object will behave in the same way as the "!", it cannot check the object inside the collection with the compiler. So I don't say that there are not also other problems with i.e. IntelliSense or the use of non-typed collections.
I write another example which maybe make it clearer what I mean:
Maybe you think it's a story only but it happened to me in the past and also to others if you search through different Access forums. I unfortunately have no example to prove that, but that's not important - if it CAN happen (oh, sorry, if it can happen) and I have a clear way of avoiding an issue with that then I of course do that.
Please also remember what I said about clear code and possibility to distinguish between field and control object simply by name, so it's another reason if the story is to vague for you.
Another often heard point is that "!" is more performant. Let's see what happens here (I tested only seconds so I didn't use Timer):
12
8
So we also get a better performance using the object notation ".". And why is that the case? Because the VBA interpreter must check anything after the first "!" and again after the second "!" if the object exist. It doesn't need that in case of the dot: The compiler did it once and that's enough. Moreover you would not get an IntelliSense support in the sample above as "Forms" cannot return an IntelliSense contents - in opposite to the class module name which uses the only loaded instance of the form (which in most cases is only one, in an object way of opening a form that would of course not be possible).
Two more reasons not to use "!": The performance is better using "." and also the IntelliSense support is better.
Still only an opinion?...;-)
Cheers,
Christian
no, no, that big letter writing was not ment to be anything personal, it was only ment as accentuation, maybe I should write such things in italic letters or anything like that - sorry. It is really sometimes difficult to write something in a way that others understand the way it was meant to be understood, that's a problem in all written communication.
Be sure that I don't take anything here personal, in the same way I do not want to affront someone with what I write.
You are of course right in comparing the statements about using a variable with the dot is also not possible and you are also right that the compiler can also not test the value if you use a literal as index in a collection. In that case I always use a constant so the compiler can at least check the constant - and I only need to check the value of the constant once, but can use it as often as I want. That's another "must have" I try to not forget that whenever I use literals, always working with constants, variables or values coming from a settings table.
You're also right that using a collection object will behave in the same way as the "!", it cannot check the object inside the collection with the compiler. So I don't say that there are not also other problems with i.e. IntelliSense or the use of non-typed collections.
I write another example which maybe make it clearer what I mean:
Me.Controls("MyCheckBox").BackColor = RGB(100, 0, 0)
Me!MyCheckBox.BackColor = RGB(100, 0, 0)
Me.MyCheckBox.BackColor = RGB(100, 0, 0)You're stating the point as if we were saying Bang is the only method to achieve anything.Sorry, that was a misunderstanding, I didn't want to say that. I only say, there is NO advantage using the bang over a dot, so why should one use it?
That would imply a major failing in Access (i.e. a bug)We all know that Access and also VBA is not free of bugs...:-)
Maybe you think it's a story only but it happened to me in the past and also to others if you search through different Access forums. I unfortunately have no example to prove that, but that's not important - if it CAN happen (oh, sorry, if it can happen) and I have a clear way of avoiding an issue with that then I of course do that.
Please also remember what I said about clear code and possibility to distinguish between field and control object simply by name, so it's another reason if the story is to vague for you.
Another often heard point is that "!" is more performant. Let's see what happens here (I tested only seconds so I didn't use Timer):
Public Sub TestTime()
Dim d As Date
Dim x As Long
Dim s As Variant
d = Now
For x = 1 To 1000000
s = Forms!frmTable1!Test
Next x
Debug.Print DateDiff("s", d, Now())
d = Now
For x = 1 To 1000000
s = Form_frmTable1.Test
Next x
Debug.Print DateDiff("s", d, Now())
End Sub12
8
So we also get a better performance using the object notation ".". And why is that the case? Because the VBA interpreter must check anything after the first "!" and again after the second "!" if the object exist. It doesn't need that in case of the dot: The compiler did it once and that's enough. Moreover you would not get an IntelliSense support in the sample above as "Forms" cannot return an IntelliSense contents - in opposite to the class module name which uses the only loaded instance of the form (which in most cases is only one, in an object way of opening a form that would of course not be possible).
Two more reasons not to use "!": The performance is better using "." and also the IntelliSense support is better.
Still only an opinion?...;-)
Cheers,
Christian
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
It's actually intellisense rather than the compiler that sees me use the dot more than bang.
Yes, I get compile time checking - and I'm happy to have that, but it wasn't a decisive reason for first prefering to using dot.
I still find it hard to accept that end users receiving runtime errors from using Bang are such a concern. What do your developers do when using recordsets or calling stock functions? Wait for the end users inform them of the typo bug in the mis-named field/function? (Or do they check/catch it in testing, as soon as they open their form.)
I'm curious what syntax you both use in recordsets actually. Is it:
strVariable = rst.Fields("FieldName")
That's the only way you reference recordset names?
If so - why? What advantage do you believe that is giving you?
(And please don't cite "use of variable" as that remains obvious that you'd revert to that syntax for that use.)
Yes, it's different in forms where we can make use of dot for the property convenience and conformation. But it's still a choice. Referring to a form AccessField with a bang is no less risky than doing so in a recordset, certainly typo-wise.
>> Another often heard point is that "!" is more performant.
I don't know anybody that I'd listen to who would tell that tale... I, for one, would not imply it.
None the less, performance difference between the two really doesn't come into it these days (that's an old argument from what, Access 97 days? :-p). Time the difference between a single execution, what's that? (Or do you regularly iterate a control a million times? ;-)
But even then, that still would only make is a better option.
>> Still only an opinion?...;-)
Yes - absolutely. It's is absolutely still an opinion of preference. Bang would have to be fundamentally flawed for it to be considered a non-option.
I repeat again. I use dot a vast majority of the time (not for speed anymore but the other reasons mentioned). But I would not dream of castigating someone for siding with Bang or suggest that dot is the only way.
Bear in mind - you're not trying to convince me that dot is good (you're not supposed to be anyway) - but that Bang is unaceptable. While there is even one worthwhile use of it (which should still be very much in Luke's mind given the article), then it can't be dismissed.
Unless you prefer writing out
Me.Controls("FieldName")
rather than
Me!FieldName
(I've done both of those too over time!)
Cheers
Yes, I get compile time checking - and I'm happy to have that, but it wasn't a decisive reason for first prefering to using dot.
I still find it hard to accept that end users receiving runtime errors from using Bang are such a concern. What do your developers do when using recordsets or calling stock functions? Wait for the end users inform them of the typo bug in the mis-named field/function? (Or do they check/catch it in testing, as soon as they open their form.)
I'm curious what syntax you both use in recordsets actually. Is it:
strVariable = rst.Fields("FieldName")
That's the only way you reference recordset names?
If so - why? What advantage do you believe that is giving you?
(And please don't cite "use of variable" as that remains obvious that you'd revert to that syntax for that use.)
Yes, it's different in forms where we can make use of dot for the property convenience and conformation. But it's still a choice. Referring to a form AccessField with a bang is no less risky than doing so in a recordset, certainly typo-wise.
>> Another often heard point is that "!" is more performant.
I don't know anybody that I'd listen to who would tell that tale... I, for one, would not imply it.
None the less, performance difference between the two really doesn't come into it these days (that's an old argument from what, Access 97 days? :-p). Time the difference between a single execution, what's that? (Or do you regularly iterate a control a million times? ;-)
But even then, that still would only make is a better option.
>> Still only an opinion?...;-)
Yes - absolutely. It's is absolutely still an opinion of preference. Bang would have to be fundamentally flawed for it to be considered a non-option.
I repeat again. I use dot a vast majority of the time (not for speed anymore but the other reasons mentioned). But I would not dream of castigating someone for siding with Bang or suggest that dot is the only way.
Bear in mind - you're not trying to convince me that dot is good (you're not supposed to be anyway) - but that Bang is unaceptable. While there is even one worthwhile use of it (which should still be very much in Luke's mind given the article), then it can't be dismissed.
Unless you prefer writing out
Me.Controls("FieldName")
rather than
Me!FieldName
(I've done both of those too over time!)
Cheers
Wow ... here we go AGAIN (emphasis) ... Bang vs Dot
:-(
:-(
Hi LPurvis,
I think you still didn't get my point. I say: There is simply NO advantage of using the "!" so why should I ever use it? If you think a shorter code is an advantage, yeah, that's truly your opinion.
My opinion (and that is an opinion) is that a verbose code is better understandable than any shortcut, that's why I prefer to use VB (BASIC in general) and not C, Java and similar languages.
So if you want to do that, I don't want to convince you, as I said.
For me, yes there is indeed only the rs.Fields("Field") way of writing it or in most cases additionally also rs.Fields(cMyFieldName). I do not need to search through the code to find out where I have used that and yes, I also normally do not access fields in forms not even with Me.Fieldname, if I want to do that I always create a control, a hidden, if needed, and access the field by using a compiler safe Me.ControlName where I can be sure that this will even not break if I change the RecordSource.
If you've enough time to do intensive tests, superb. But really - how often does it happen that a rarely used function was not tested in the way that the error comes up so it is indeed the end user which informs us about an error? I'm sure you do not want to say that all your programs are such perfectly tested that this NEVER happens.
So again, the point is: WHY should I use the worse technique which I can simply avoid by using another character and moreover adding more comfort in faster writing by using IntelliSense (which in some cases of course also works in using the "!")? It even happened when I wrote the time test above, I couldn't remember the correct spelling of the name of the form. Using Forms! it was not possible. Using Form_ and press ctrl-space I have a list of all forms with modules. Using Forms!frmTable1! it is not possible to find the wanted field with IntelliSense. Using Form_frmTable1.Test IntelliSense shows that to me (and that's also the reason why I rename all controls where any control which has a ControlSource has the same prefix "ctl" so I have a simple to find list of any control and with that the list of fields).
For me using the "!" is a strict no-go. And if anybody asks me I can show reasons why I think so. But nobody can show reasons why to prefer "!" over the ".", so again, I have facts, and I build my opinion from that, people who use "!" have only a preference to use it, but no facts why not use "." instead. That's pure opinion.
I go even far beyond this, although that was only an experiment and I do not use that currently in any project:
https://www.experts-exchange.com/Microsoft/Development/MS_Access/A_11029-LINQ-for-VBA-and-Typed-Tables-Queries-and-Field-Names-using-VBA.html
This makes it even possible to never need to use any manually typed constant, you can choose everything very comfortable by choosing from enums.
But I think, the discussion now doesn't lead to new knowledge, we both have said what we want and we both have our personal way of doing the things right...:-)
Cheers,
Christian
I think you still didn't get my point. I say: There is simply NO advantage of using the "!" so why should I ever use it? If you think a shorter code is an advantage, yeah, that's truly your opinion.
My opinion (and that is an opinion) is that a verbose code is better understandable than any shortcut, that's why I prefer to use VB (BASIC in general) and not C, Java and similar languages.
So if you want to do that, I don't want to convince you, as I said.
For me, yes there is indeed only the rs.Fields("Field") way of writing it or in most cases additionally also rs.Fields(cMyFieldName). I do not need to search through the code to find out where I have used that and yes, I also normally do not access fields in forms not even with Me.Fieldname, if I want to do that I always create a control, a hidden, if needed, and access the field by using a compiler safe Me.ControlName where I can be sure that this will even not break if I change the RecordSource.
What do your developers do when using recordsets or calling stock functions? Wait for the end users inform them of the typo bug in the mis-named field/function? (Or do they check/catch it in testing, as soon as they open their form.)
If you've enough time to do intensive tests, superb. But really - how often does it happen that a rarely used function was not tested in the way that the error comes up so it is indeed the end user which informs us about an error? I'm sure you do not want to say that all your programs are such perfectly tested that this NEVER happens.
So again, the point is: WHY should I use the worse technique which I can simply avoid by using another character and moreover adding more comfort in faster writing by using IntelliSense (which in some cases of course also works in using the "!")? It even happened when I wrote the time test above, I couldn't remember the correct spelling of the name of the form. Using Forms! it was not possible. Using Form_ and press ctrl-space I have a list of all forms with modules. Using Forms!frmTable1! it is not possible to find the wanted field with IntelliSense. Using Form_frmTable1.Test IntelliSense shows that to me (and that's also the reason why I rename all controls where any control which has a ControlSource has the same prefix "ctl" so I have a simple to find list of any control and with that the list of fields).
For me using the "!" is a strict no-go. And if anybody asks me I can show reasons why I think so. But nobody can show reasons why to prefer "!" over the ".", so again, I have facts, and I build my opinion from that, people who use "!" have only a preference to use it, but no facts why not use "." instead. That's pure opinion.
I go even far beyond this, although that was only an experiment and I do not use that currently in any project:
https://www.experts-exchange.com/Microsoft/Development/MS_Access/A_11029-LINQ-for-VBA-and-Typed-Tables-Queries-and-Field-Names-using-VBA.html
This makes it even possible to never need to use any manually typed constant, you can choose everything very comfortable by choosing from enums.
But I think, the discussion now doesn't lead to new knowledge, we both have said what we want and we both have our personal way of doing the things right...:-)
Cheers,
Christian
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> I think you still didn't get my point. I say: There is simply NO advantage of using the "!" so why should I ever use it?
You're massively missing my point. As, possibly, is everyone it seems.
This is not Bang Vs Dot. I've written soo many post about that it's untrue - massive ones and I won't be doing so again here.
This is about assertions that there is only one way - when in fact there are options.
Personal opinion presented as the only option. I hate seeing that.
I tried to go gently about it (Gustav was a bit more forthright) and perhaps I shouldn't have. It's seemingly confused the issue.
Why would anyone ever use Bang? I thought we'd covered that... On forms who's record source changes.
>> If you think a shorter code is an advantage, yeah, that's truly your opinion.
That's not my point nor have I ever said that shorter code is my objective here. (Efficient code massively yes, but long code whe it's not required is just that.... long code - unrequired.)
My point is, if you assert there's no point in ever using Bang, then what is the point in
Me.Recordset.Fields("Field
Anyway. It's a moot point now.
Sorry to the OP if this all seems lost in the wash now.
Must get back home...
You're massively missing my point. As, possibly, is everyone it seems.
This is not Bang Vs Dot. I've written soo many post about that it's untrue - massive ones and I won't be doing so again here.
This is about assertions that there is only one way - when in fact there are options.
Personal opinion presented as the only option. I hate seeing that.
I tried to go gently about it (Gustav was a bit more forthright) and perhaps I shouldn't have. It's seemingly confused the issue.
Why would anyone ever use Bang? I thought we'd covered that... On forms who's record source changes.
>> If you think a shorter code is an advantage, yeah, that's truly your opinion.
That's not my point nor have I ever said that shorter code is my objective here. (Efficient code massively yes, but long code whe it's not required is just that.... long code - unrequired.)
My point is, if you assert there's no point in ever using Bang, then what is the point in
Me.Recordset.Fields("Field
Anyway. It's a moot point now.
Sorry to the OP if this all seems lost in the wash now.
Must get back home...
Hi mx,
it's OK if you want to do that, but that's only because you prefer to do so, nothing else.
I like your disclaimer...:-)
Hi LPurvis,
maybe you mixed up older discussions with what I've said. When did I wrote that the dot is the only possibility? I quote myself from the initial post: "ALWAYS use the "." to make sure the compiler can check anything behind, the "!" will prohibit any check after this sign." There is no "you cannot use the !".
More and more it seems that you are the one of us which takes this thing personal...I only wanted to discuss that as you opened it for discussion...:-)
Was not my intention to make you angry, so if you are, I beg your pardon.
Cheers,
Christian
it's OK if you want to do that, but that's only because you prefer to do so, nothing else.
I like your disclaimer...:-)
Hi LPurvis,
maybe you mixed up older discussions with what I've said. When did I wrote that the dot is the only possibility? I quote myself from the initial post: "ALWAYS use the "." to make sure the compiler can check anything behind, the "!" will prohibit any check after this sign." There is no "you cannot use the !".
More and more it seems that you are the one of us which takes this thing personal...I only wanted to discuss that as you opened it for discussion...:-)
Was not my intention to make you angry, so if you are, I beg your pardon.
Cheers,
Christian
"it's OK if you want to do that, but that's only because you prefer to do so, nothing else."
On the contrary ... if refutes this comment:
"Using the "!" should in my opinion ALWAYS be avoided in VBA, there is NO need to use it!"
The is *no* reason to always avoid it.!!..! :-)
:-)
On the contrary ... if refutes this comment:
"Using the "!" should in my opinion ALWAYS be avoided in VBA, there is NO need to use it!"
The is *no* reason to always avoid it.!!..! :-)
:-)
ASKER
guys, in my opinion i always avoid ! because if i were to work in the library and the librarian walked behind me and saw me typing so many !s i would get chased out immediately!!!! KEEP QUIET IN THE LIBRARY!!!!
hahahahhaa but yup yup guys, library aside, i think that yall all have fantastic opinions and it's great for someone who's just learning VBA like me to learn and hear your opinions! thanks so much for all your sharing guys!! = ))
hahahahhaa but yup yup guys, library aside, i think that yall all have fantastic opinions and it's great for someone who's just learning VBA like me to learn and hear your opinions! thanks so much for all your sharing guys!! = ))
of course you can say it is only an opinion, and Gustav, only because you are always using the "!" doesn't mean that this is the correct way. You CAN jump from the bridge to get into the water but you can also think about if it wouldn't be better to go over the bridge and down to the water to jump into it very safe. The first method is possible, but you will most likely die.
I know that this theme always creates big discussions and that there are also different opinions in there, I also know that MS themselves recommending the use of "!" (but we all know the quality of MS recommendations, to mention only DAO/ADO/DAO...).
If you think about it, WHEN makes a "!" really sense in VBA? I say absolutely and with no exception: In NO situation. The "!" makes it impossible to let the compiler do a check for anything later in the line. So simply don't use it.
In special cases like the mentioned change of a RecordSource you, LPurvis, have already written the alternative to dynamically access the field without issues, using the Fields collection of the recordset object. If you change a RecordSource dynamically, you most likely do have a list of the used fields as variables or constants or you read that out of a table and so you can insert the variable here without any problem. You can't use "Me!MyVariableName" to access "MyField".
In opposite I can simply write "Me!Mickymaus" in the code and the compiler will ignore it, but my runtime will throw an error which I could have avoided if I had the compiler check all the names.
So please: Give me ANY example where the "!" makes sense over "." (except the already mentioned expressions in forms/queries where you are forced to use it).
It's similar in case of the "don't use the same names for Controls and Fieldnames". Sure, Access will create a property in the form with the control name and normally you can be sure that the control name has the priority when Access searches the name. But "normally" is not enough, sometimes Access finds the field name property before the control name and then you could not access the BackColor property for example because your code currently works with the field which only has the Value property. Moreover the code will be more readable as you can see from the name of the control that you definitely are using the control and not the underlying field.
These methods both help to write better programs and cleaner code. Maybe others have other opinions and I don't want to CONVINCE anybody but if someone asks me to give mine, that's it and in my opinion there is a clearly NEVER and ALWAYS.
Cheers,
Christian