Results 1 to 14 of 14
  1. #1
    GraeagleBill's Avatar
    GraeagleBill is offline Experienced Old Geezer
    Windows 10 Access 2013 32bit
    Join Date
    Feb 2011
    Posts
    1,919

    Going "bonkers" with "data member not found" error

    On my A2003 system, I have an app with a form that contains a text box "tbSelAro". That text box is bound to a table field, "SelAro", that is returned by the query that is the RecordSource for the form. Pretty simple eh?



    The 1st screenshot is the text box properties:
    Click image for larger version. 

Name:	001.jpg 
Views:	19 
Size:	59.3 KB 
ID:	26693

    The 2nd screenshot is the form's property sheet referencing the "Mouse Down" procedure. (Not very interesting, just for completeness sake.)
    Click image for larger version. 

Name:	002.jpg 
Views:	19 
Size:	63.4 KB 
ID:	26694

    The 3rd screenshot is the "Mouse Down" procedure where the error occurs:
    Click image for larger version. 

Name:	003.jpg 
Views:	19 
Size:	123.2 KB 
ID:	26695

    This is about as straight forward as one can get, yet the system cannot find "SelAro" when one attempts to compile the app. I have run the RecordSource query by itself and examined for the presence of "SelAro" as well as selecting the "SelAro" field repeatedly within the text boxes ControlSource to insure Access recognizes the RecordSource field name. Lastly, I have searched the field dropdown list for the "Me." and "SelAro" IS NOT among the choices.

    Thoughts please,
    Bill

  2. #2
    aytee111 is offline Competent At Times
    Windows 7 32bit Access 2013 32bit
    Join Date
    Nov 2011
    Location
    Nomad
    Posts
    3,936
    When referring to a control on a form, Access sometimes used the Name property and sometimes uses the Control Source. Either figure out when each one is used - or do what most of us do, call them both by the same name!

  3. #3
    CJ_London is offline VIP
    Windows 10 Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    11,397
    As aytee111 says

    me.Selarc - Selarc is not a valid control name - it should be me.tblSelarc

    if you want to refer to the field itself you would use

    me!Selarc

    me. refers to the controls

  4. #4
    GraeagleBill's Avatar
    GraeagleBill is offline Experienced Old Geezer
    Windows 10 Access 2013 32bit
    Join Date
    Feb 2011
    Posts
    1,919
    Interesting! I've always made it a practice to set the control's name to "tb"ControlSourceName and refer in code with that name. Why that got by me today is anyone's guess. I have two other apps that employ a similar approach to dynamically selecting a subset of the current form's recordset and both refer to the content of the text box via Me.ControlSourceName. You can be sure I'm going to update those two apps before a "snake in the grass" hits one of my users.

    Thanks a bunch,
    Bill

  5. #5
    CJ_London is offline VIP
    Windows 10 Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    11,397
    my policy is bound controls - name the same as the field. unbound controls prefix with txt, cbo etc

  6. #6
    GraeagleBill's Avatar
    GraeagleBill is offline Experienced Old Geezer
    Windows 10 Access 2013 32bit
    Join Date
    Feb 2011
    Posts
    1,919
    It's been years since I encountered problems with control names and ControlSource names the same, probably A2000. Also, if my memory serves me at all the issue arose with reports not forms.

  7. #7
    John_G is offline VIP
    Windows 7 32bit Access 2010 32bit
    Join Date
    Oct 2011
    Location
    Ottawa, ON (area)
    Posts
    2,615
    That error will go away if you use the bang (!) instead of a a period, i.e. use me!Selarc. Access used to be quite forgiving about which one you used, but it has become less so. Making it a habit to always use ! to refer to form/report controls and recordset members reduces the chances of errors and makes code a bit easier to read because you (or anyone else!) will know what you are referring to.

  8. #8
    GraeagleBill's Avatar
    GraeagleBill is offline Experienced Old Geezer
    Windows 10 Access 2013 32bit
    Join Date
    Feb 2011
    Posts
    1,919
    Access used to be quite forgiving about which one you used, but it has become less so.
    Yes, It would seem that it was my desktop A2013 versus laptop at A2003 that caused your very point to manifest. I've relied on my practice of using name prefixes, "tb", "cbo", "cmd", etc., with "Me." to refer to controls versus no prefixes to refer to recordset members that until now at A2013 I'm left with a bit of a dilemma. Since the preponderance of my apps use bound controls by habit together with "Me.prefix........" names, I'll hopefully not have a major disaster on my hands. But as the recent experience teaches, there could be a few exceptions lurking. I have literally thousands of lines of code among my apps so there could be trouble ahead. Edit > Replace All Me.tb with Me!tb would likely be safe, but the thought of such a pervasive change would be scary at best!

    My field locations are all split configurations with mde front ends which shouldn't be a problem. I'll just need to be more cognizant of potential compiler errors if and when my apps are being revised in a A2013 environment.

    You have made an excellent point and I thank you for that.

    Bill

  9. #9
    GraeagleBill's Avatar
    GraeagleBill is offline Experienced Old Geezer
    Windows 10 Access 2013 32bit
    Join Date
    Feb 2011
    Posts
    1,919
    Thanks too to Aytee111 and Ajax.
    Bill

  10. #10
    GraeagleBill's Avatar
    GraeagleBill is offline Experienced Old Geezer
    Windows 10 Access 2013 32bit
    Join Date
    Feb 2011
    Posts
    1,919
    As an aside, I have to laugh when I think about all the code I've written with DAO and cloned recordsets where member names are identified with the splat "!".

  11. #11
    Micron is offline Virtually Inert Person
    Windows 7 32bit Access 2007
    Join Date
    Jun 2014
    Location
    Ontario, Canada
    Posts
    12,737
    This is the best explanation of the bang operator I've seen (and I quote)
    The bang operator provides late-bound access to the default member of an object, by passing the literal name following the bang operator as a string argument to that default member.

    This would suggest that the default member of a form is its collection of fields (which I cannot ascertain) which is why what Ajax said would work. Since ! is late bound, it will not raise an error during a compile, though the line might generate an error for some other reason. Thus I don't agree that Me. is specifically a way to refer to form (or report) controls since
    Msgbox Me.txtMytextbox
    will produce exactly the same result as
    Msgbox Me!txtMytextbox

    regardless of whether the control is bound or not.

    We all have our own methods that work (most of the time?) and I for one never name a control the same as the field it is bound to. I have run into cases where the ambiguity of that caused me a problem because Access cannot figure out if you're referring to the field or the control. I can't recall the details of the problem; suffice to say I have never named the two the same since.

    Sorry if I misinterpreted anything that was said here.
    The more we hear silence, the more we begin to think about our value in this universe.
    Paraphrase of Professor Brian Cox.

  12. #12
    GraeagleBill's Avatar
    GraeagleBill is offline Experienced Old Geezer
    Windows 10 Access 2013 32bit
    Join Date
    Feb 2011
    Posts
    1,919
    "Holy Objects Batman!" (for you old guys ), I have a fundamental misunderstanding laid bare with this current issue. Namely that default members are considered late-bound by the compiler. Probably a faulty assumption on my part from years past, but in thinking that the tabledefs provided the explicit about the object that early-binding was possible. Also, from the discussions here and elsewhere that default members are not considered "objects" in and of themselves? I.e., the Fields collection is treated as an object but members of the collection ARE NOT?

  13. #13
    Micron is offline Virtually Inert Person
    Windows 7 32bit Access 2007
    Join Date
    Jun 2014
    Location
    Ontario, Canada
    Posts
    12,737
    Namely that default members are considered late-bound by the compiler.
    Not sure you can say that (I didn't). The explanation is saying that the bang operator provides late bound access to the default member of an object. AFAIK most (many?) late bound references don't trigger a compile error - at least with things like late bound referencing to Automation objects and the like.

    Not sure I agree with the Fields collection is treated as an object. I think I've always considered a collection to be a set (i.e. collection) of similar objects, such as tables, queries, reports, forms, etc. but members of the collection ARE NOT? Definitely don't agree that collection members are not objects as just mentioned. Whether or not a collection is an object is not important to me, but it probably is since it's exposed like any other object, and after all, Access is all about Object Oriented Programming.

  14. #14
    ssanfu is offline Master of Nothing
    Windows XP Access 2010 32bit
    Join Date
    Sep 2010
    Location
    Anchorage, Alaska, USA
    Posts
    9,664
    Quote Originally Posted by Micron View Post
    <snip>
    and I for one never name a control the same as the field it is bound to. I have run into cases where the ambiguity of that caused me a problem because Access cannot figure out if you're referring to the field or the control. I can't recall the details of the problem; suffice to say I have never named the two the same since.

    <snip>
    Agree with Micron on this point:
    I also had a few cases where Access got confused (or was it me that was confused) about referring to a field or control.
    So I also always rename a control different than the name of the bound field.
    (I still bounce back and forth between using the dot and the bang, but so far no errors that I noticed.)

    My $0.02 ............

Please reply to this thread with any new information or opinions.

Similar Threads

  1. Replies: 1
    Last Post: 09-07-2015, 08:00 AM
  2. Suppress "Error" message following "Cancel = True"
    By GraeagleBill in forum Programming
    Replies: 7
    Last Post: 03-23-2014, 05:40 PM
  3. DAO .Edit "Method or data member not found"
    By GraeagleBill in forum Programming
    Replies: 3
    Last Post: 09-05-2013, 02:10 PM
  4. "Method or data member not found"
    By GraeagleBill in forum Programming
    Replies: 6
    Last Post: 08-17-2013, 05:23 PM
  5. "Group By" causes "ODBC--Call Failed" error
    By kaledev in forum Queries
    Replies: 1
    Last Post: 03-09-2011, 02:43 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums