"Object doesn't support this property or method"

[Bill]

In the process of creating some code structure, I inserted
some verification code to insure proper "addressabiltiy" to
some table fields taken from the current forms RecordSource.
In the segment of code below, both WorksID and Title are
table fields defined by the current query. WorksID (and others
that I also tried) display as expected. However, in attempting
to display the current value of "Title", I get the Access diagnostic:
"Object doesn't support this property or method" I've visually
verified that "Title" is indeed defined by the form's RecordSource
and that there's no conflict with the name of the text-box that
it is bound to.

I assume it's staring me in the face, but I still don't see the
problem?

Thanks,
Bill

Private Function Replicate()
'========================================================
'Replicate the current entry on a different volume.
'========================================================
MsgBox Me.WorksID
MsgBox Me.Title
End Function

 

[Marshall Barton]

In the process of creating some code structure, I inserted
some verification code to insure proper "addressabiltiy" to
some table fields taken from the current forms RecordSource.
In the segment of code below, both WorksID and Title are
table fields defined by the current query. WorksID (and others
that I also tried) display as expected. However, in attempting
to display the current value of "Title", I get the Access diagnostic:
"Object doesn't support this property or method" I've visually
verified that "Title" is indeed defined by the form's RecordSource
and that there's no conflict with the name of the text-box that
it is bound to.

Private Function Replicate()
'========================================================
'Replicate the current entry on a different volume.
'========================================================
MsgBox Me.WorksID
MsgBox Me.Title
End Function

You've done all the right checks so far, but the error still
points to Title as a nonexistent field. What happens when
you type the dot after Me? You should see the intellisense
list and be able to select Title (however it's spelled).

Grasping at a very thin straw here, but on rare occasions, I
have had an invisible character somewhere in a name, so it
might be worthwhile to retype the name in both the query and
the code. The only other straw is can think to grasp at is
that Title may be a reserved word and maybe you can get past
it by using Me!Title??

 

[Bill]

Marsh,
I've used "intellisense" with "Me dot" to select the field name;
verified that the name was un-contaminated by dragging
the name from the table into the query and checked the
form's property sheet by using the drop-down list of
fields defined for use in the form's code-sheet. Last, but
not least, I tried to reference the field using the Me!Title
syntax, but I still get the same error.

I double-checked the name of the control versus the name
of the bound field, but they are sufficiently different that I'm
confident that I'm not confusing Access.

At this point I'm clueless.

Bill

 

[Dirk Goldgar]

In the process of creating some code structure, I inserted
some verification code to insure proper "addressabiltiy" to
some table fields taken from the current forms RecordSource.
In the segment of code below, both WorksID and Title are
table fields defined by the current query. WorksID (and others
that I also tried) display as expected. However, in attempting
to display the current value of "Title", I get the Access diagnostic:
"Object doesn't support this property or method" I've visually
verified that "Title" is indeed defined by the form's RecordSource
and that there's no conflict with the name of the text-box that
it is bound to.

I assume it's staring me in the face, but I still don't see the
problem?

It's not obvious, Bill. If the form's recordsource is a query, not a
table, would you care to post the SQL of that query?

 

[Bill]

Gladly...............

SELECT Works.WorksID, Works.CompID, Composers.CompLast, Works.Title,
Orchestra.Orchestra, Conductors.CondLast, Volumes.CtlgNo, Works.GenreID,
Works.GAPPerf
FROM Volumes INNER JOIN (Orchestra INNER JOIN (Genre INNER JOIN (Conductors
INNER JOIN (Composers INNER JOIN Works ON Composers.CompID = Works.CompID)
ON Conductors.CondID = Works.CondID) ON Genre.GenreID = Works.GenreID) ON
Orchestra.OrchID = Works.OrchID) ON Volumes.VolID = Works.VolID
ORDER BY Composers.CompLast;

Note that the query has been in production for a couple of
years and the field "Title" has been bound to the text-box
control for that same amount of time without incident.
EXCEPT that now is the first time I've made reference
to that field in code. AND, "Works.GAPPerf" was a
recently added field to the "Works" table.

I have no way of showing you the relationship graphics
without an image but, once again, other than the addition
of the "GAPPerf" field there's been no other changes to
the query.

By-the-way, I use the design-sheet layout to build the queries
rather than code them by hand.

Still clueless.

Off to bed, I'll be back in the AM.

Thanks,
Bill
Graeagle, CA

 

[Marshall Barton]

Maybe Dirk has some ideas, but I'm stumped. At this point
I'm going to have to resort to the corruption cop out. If
you haven't already tried it, create a new blank mdb file
with all the right settings and references, then import
everything from the problem mdb.

 

[Bill]

Marsh,
I imported all the tables, forms, reports, modules, etc. into
a new mdb. Then I inserted "MsgBox Me.Title" into the
OnOpen code but I get the same error when I open the
form. I then verified that other fields are readily addressable,
e.g., MsgBox me.CompID displays the current value of
CompID .

My scalp is getting soar from scratching my head!

Bill

Maybe Dirk has some ideas, but I'm stumped. At this point
I'm going to have to resort to the corruption cop out. If
you haven't already tried it, create a new blank mdb file
with all the right settings and references, then import
everything from the problem mdb.
--
Marsh
MVP [MS Access]

I've used "intellisense" with "Me dot" to select the field name;
verified that the name was un-contaminated by dragging
the name from the table into the query and checked the
form's property sheet by using the drop-down list of
fields defined for use in the form's code-sheet. Last, but
not least, I tried to reference the field using the Me!Title
syntax, but I still get the same error.

I double-checked the name of the control versus the name
of the bound field, but they are sufficiently different that I'm
confident that I'm not confusing Access.



"Marshall Barton"wrote

 

[Marshall Barton]

What the heck is going on here???

Did you check for the possibility of a name conflict by
aliasing the title field in the query?

 

[Bill]

I FOUND IT!!!! My wicked past has caught up with me!

I confused Access with some names. As most of you already
know, one ought not use the same name for form controls as
the name of the control source for that control. That axiom
extends to ANY duplication of names amongst controls and
control sources of a given form or its sub-forms. I was un-aware
of that axiom a few years back when this application was first
coded, so that snake was laying in the grass just waiting for me.

The offending duplication was somewhat far removed from the
text-box control bound to "Title", but nonetheless there was a column
heading label in the forms header section with the same name.

Sorry to have taken so much of your time on this one.

Thanks,
Bill

 

[Bill]

Marsh,
I just posted my embarrassing confession. So again, I'm
sorry to have taken so much of your time.
Bill

What the heck is going on here???

Did you check for the possibility of a name conflict by
aliasing the title field in the query?
--
Marsh
MVP [MS Access]

I imported all the tables, forms, reports, modules, etc. into
a new mdb. Then I inserted "MsgBox Me.Title" into the
OnOpen code but I get the same error when I open the
form. I then verified that other fields are readily addressable,
e.g., MsgBox me.CompID displays the current value of
CompID .


"Marshall Barton" wrote

 

[Dirk Goldgar]

I FOUND IT!!!! My wicked past has caught up with me!

You knew it had to happen.

[...] As most of you already
know, one ought not use the same name for form controls as
the name of the control source for that control.

I disagree. Some people do argue that, and it may help a developer to
make a clear distinction between controls and fields, but it has always
been my experience that Access is perfectly happy giving bound controls
the same names as their controlsources. It's my habit to name bound
controls this way unless I plan to write code that has a need to
distinguish between the control (and its properties) and the field
itself.

That axiom
extends to ANY duplication of names amongst controls and
control sources of a given form or its sub-forms.

That's another matter altogether. Duplicate names for controls or
properties in the same scope will certainly cause problems.

The offending duplication was somewhat far removed from the
text-box control bound to "Title", but nonetheless there was a column
heading label in the forms header section with the same name.

So let me see if I understand what happened. You had a control with a
unique name -- call it "txtControl", bound to a field named "Title", and
you also had a label control named "Title"? Yes, that would cause a
problem. But note that, if your text box had actually been named
"Title", you wouldn't have been able to create a label on the form with
that name. So actually, in this case your problem was caused -- or at
least, permitted -- by *not* giving the text box the same name as its
bound field.

 

[Bill]

Dirk,
A couple of years ago, I had a problem wherein a control on
a A2K Report had the same name as its controlsource. Access
kept displaying #ERROR whenever the report would run. It
was out of that experience that I adopted the practice of not
naming controls the same as the fields they were bound to.
Obviously, I carried that practice to forms as well.

And yes, had I named the textbox control the same as its
bound source, I wouldn't have been able to name the label
control with the same name. Everything would have continued
without errors had I not suddenly modified old code-sheets
with the inclusion of references to the field "Title", also the
name of the label control. However, I didn't have enough
experience to foresee if code references would be a future
likelihood, as you mentioned in your own considerations.

These days, all of my new designs use a convention of
LBLname for label controls and Ctlname for text box controls
in order to ward off the possibilities of confusing ME, Access
notwithstanding.

Thanks for your thoughts on this subject,
Bill

I FOUND IT!!!! My wicked past has caught up with me!

You knew it had to happen.

[...] As most of you already
know, one ought not use the same name for form controls as
the name of the control source for that control.

I disagree. Some people do argue that, and it may help a developer to
make a clear distinction between controls and fields, but it has always
been my experience that Access is perfectly happy giving bound controls
the same names as their controlsources. It's my habit to name bound
controls this way unless I plan to write code that has a need to
distinguish between the control (and its properties) and the field
itself.

That axiom
extends to ANY duplication of names amongst controls and
control sources of a given form or its sub-forms.

That's another matter altogether. Duplicate names for controls or
properties in the same scope will certainly cause problems.

The offending duplication was somewhat far removed from the
text-box control bound to "Title", but nonetheless there was a column
heading label in the forms header section with the same name.

So let me see if I understand what happened. You had a control with a
unique name -- call it "txtControl", bound to a field named "Title", and
you also had a label control named "Title"? Yes, that would cause a
problem. But note that, if your text box had actually been named
"Title", you wouldn't have been able to create a label on the form with
that name. So actually, in this case your problem was caused -- or at
least, permitted -- by *not* giving the text box the same name as its
bound field.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)