incorrect METHOD OR DATA MEMBER NOT FOUND compile error

  • Thread starter Thread starter Angelo
  • Start date Start date
A

Angelo

I'm running Access 97 on Windows NT

I've coded about a gazillion Access data forms and this is
the first time I've seen this.

I've got a complex form with about 45 bound text boxes in
the DETAIL section and about 20 or so command boxes. I
know this sounds like a BUSY form that should be
separated, but most of the commands are tucked nicely in
TABS, headers and footers making things compact like my
people want.

Problem - Phase 1.
-----------------
I had a field txtPartNumber which would not show it's
refreshed value with all the other data fields on the
form. Me.Refresh and me.repaint and me.Requery did not
resolve the problem. So, I renamed the fields to
something else and received the following problem.

Prolem - Phase 2.
-----------------
Now is for the first time, I'm getting a METHOD OR DATA
MEMBER NOT FOUND compile error on a text box that
definately is there. I verified that typing in ME. in the
code brings up the text box name - so I know it is being
recognized, but when I compile (or try to run the code) I
get the METHOD OR DATA MEMBER NOT FOUND error. At this
point, there is nothing I could do to get around the error
except to drop the fields and re-add them. Then I get
problem 1 again.

Anyone got any clues for a clueless guy!

Thanx!

Angelo
 
Problem: Phase 1 - can you describe the activity/logic that's going on with
your Control, txtPartNumber? Is it bound to a field in the form's Record
Source? If so, what is the field's name? Can you post any relevant code?

Problem: Phase 2 - I doubt that renaming the controls will solve the
problem. However, I have seen the METHOD OR DATA MEMBER NOT FOUND problem
occur when I have inadvertently used a Reserved Word as the name of a
control and then referred to it in code using the DOT (.) instead of BANG
(!).
 
Problem Solved:

Since you mentioned the DOT vs BANG thing, I decided to
look for inadvertant DOTs. I found 2 instances where I
used the me.PartNumber instead of me.txtPartNumber.

PartNumber is the database field to which txtPartNumber is
bound. I didn't think me.<FieldName> was valid - only
me.<controls>! I thought me.<FieldName> would have given
em a compile error.
What does me.<FieldName> represent? It updates the
database field immediately, but doesn't update the field
it is bound to until I scroll that record off the screen
and back on again! Goes to show you how much I know!

Anyhow - THANX A MEG for the help! (Please note that THANX
is bold, 24 pt, Underlined, Royal Blue, and highlighted
with a red highlighter. You pointed me in the right
direction and now I'm a happy camper!

P.S. Are you a Microsoft Representative or just someone
like me sharing your knowlege. I was wondering if it was
kosher for me to Post Replies to others.
 
You're welcome, Angelo! No, I'm not a Microsoft Rep or employee. Like
you, just a working (sometimes) programmer who has learned a lot from her
mistakes and even more from this NG. Should you post replies? If you know
the answer and can help - sure!
What does me.<FieldName> represent? It updates the
database field immediately, but doesn't update the field
it is bound to until I scroll that record off the screen
and back on again! Goes to show you how much I know!
Click to expand...

What I *think* is happening is that if the ControlName is not equal to the
ControlSource (FieldName), the record has to be saved and the form refreshed
before everything gets resolved. But, this is just a guess. Perhaps one of
the MVPs can shed some light.
 
Back
Top