Compile Database Code Problem

[Dan]

I need to convert a database to ACCDE and need to compile my VBA, however
when I select Compile under the Debug menu I get the following error, "Method
or data member not found".

The problem is that the Sub it is identifing is a part of my database and
works well when I use the database.

The code that failed was the following with ".Combo2" highlighted in the
second line.

Private Sub Combo2_AfterUpdate()
TransferSection = Me.Combo2
MsgBox "Transfer Section is " & TransferSection
RunCommand acCmdRecordsGoToNew
RunCommand acCmdSelectRecord
RunCommand acCmdPaste
RunCommand acCmdSelectRecord
Me.[Inspection Section] = TransferSection
Me.Combo2.Visible = False
Me.Refresh
End Sub

Thanks for the help
Dan

 

[Dirk Goldgar]

I need to convert a database to ACCDE and need to compile my VBA, however
when I select Compile under the Debug menu I get the following error,
"Method
or data member not found".

The problem is that the Sub it is identifing is a part of my database and
works well when I use the database.

The code that failed was the following with ".Combo2" highlighted in the
second line.

Private Sub Combo2_AfterUpdate()
TransferSection = Me.Combo2
MsgBox "Transfer Section is " & TransferSection
RunCommand acCmdRecordsGoToNew
RunCommand acCmdSelectRecord
RunCommand acCmdPaste
RunCommand acCmdSelectRecord
Me.[Inspection Section] = TransferSection
Me.Combo2.Visible = False
Me.Refresh
End Sub

Hmm. Verify that the combo box is still named "Combo2"; that you didn't
rename it at some point, leaving this orphan Sub behind.

 

[John W. Vinson]

I need to convert a database to ACCDE and need to compile my VBA, however
when I select Compile under the Debug menu I get the following error, "Method
or data member not found".

The problem is that the Sub it is identifing is a part of my database and
works well when I use the database.

The code that failed was the following with ".Combo2" highlighted in the
second line.

Private Sub Combo2_AfterUpdate()
TransferSection = Me.Combo2
MsgBox "Transfer Section is " & TransferSection
RunCommand acCmdRecordsGoToNew
RunCommand acCmdSelectRecord
RunCommand acCmdPaste
RunCommand acCmdSelectRecord
Me.[Inspection Section] = TransferSection
Me.Combo2.Visible = False
Me.Refresh
End Sub

Thanks for the help
Dan

That suggests that there is no object named Combo2.

You also haven't dimensioned TransferSection - is that a control on your form?

 

[David W. Fenton]

I need to convert a database to ACCDE and need to compile my VBA,
however when I select Compile under the Debug menu I get the
following error, "Method or data member not found".

This is the kind of thing that puzzles me. While it may not be your
database and you are just taking over responsibility for it,
somebody was responsible for creating a database that doesn't
compile.

This is malpractice, in my opinion. It may indicate incompetence.

Compiling is something an Access developer should do FREQUENTLY,
like EVERY FIVE MINUTES. I do it after every few lines of code. Why?
Because it catches my typos and insures that my app is always
compilable.

Here are some basic best practices for developing in Access:

1. in VBE options, turn off COMPILE ON DEMAND.

2. make sure you have OPTION EXPLICIT in all modules (this is a
setting in VBE options, i.e., REQUIRE VARIABLE DECLARATION should be
turned on).

3. in the VBE, add the compile button to your toolbar so it's very
easy to compile on the fly (I also add the CALL STACK button, too,
as it makes it easier to navigate in break mode).

4. periodically decompile/recompile to insure that no crud
accumulates in your VBA project.

5. in code, always specify parent objects. You can get away with not
doing it, but it's not a good idea. That is, in a form module's
code, you can use txtLastName to refer to a control, but it's better
to use Me!txtLastName (my preference) or Me.txtLastName. This makes
the code clearer and makes it more manageable in the long run, as
well as making it easier for the compiler (which may make mistakes
if you aren't explicit).

This is all so basic I am always surprised when people don't know
these things.

 

[George Hepworth]

Re point 5: I've heard the claim that code runs faster with qualified
references . The claim was made at a user group meeting by someone I
consider credible, but I don't have any empirical experience to back it up.

 

[Paul Shapiro]

This is the kind of thing that puzzles me. While it may not be your
database and you are just taking over responsibility for it,
somebody was responsible for creating a database that doesn't
compile.

This is malpractice, in my opinion. It may indicate incompetence.

Compiling is something an Access developer should do FREQUENTLY,
like EVERY FIVE MINUTES. I do it after every few lines of code. Why?
Because it catches my typos and insures that my app is always
compilable.

I took over an application which did not compile from another developer. He
insisted there was no reason code that wasn't being used needed to compile!
I guess that's at least part of why he's no longer the developer. I created
a new database, imported just the objects that I knew were in use, and
updated the code until the application compiled. As users worked with the
app I told them to let me know if they got errors about missing objects, and
then I added those and fixed the code. I couldn't tell for sure what was
needed because some of the menu items and command buttons had never worked
or were never used, but no one was able/willing to go through the whole
application listing the necessary elements.

 

[David W. Fenton]

Re point 5: I've heard the claim that code runs faster with
qualified references . The claim was made at a user group meeting
by someone I consider credible, but I don't have any empirical
experience to back it up.

It would stand to reason, as VBA has to look it up if it's not
specified (in order to validate the code).

 

[David W. Fenton]

I took over an application which did not compile from another
developer. He insisted there was no reason code that wasn't being
used needed to compile!

Well, to be fair, he might have been a long-time Access developer
and accustomed to relying on that in A95/A97, where modules *were*
independently compiled. Starting with A2000, the VBA project is all
one big meta-module, and all of it has to compile.

I guess that's at least part of why he's no longer the developer.
Heh.

I created a new database, imported just the objects that I knew
were in use, and updated the code until the application compiled.
As users worked with the app I told them to let me know if they
got errors about missing objects, and then I added those and fixed
the code. I couldn't tell for sure what was needed because some of
the menu items and command buttons had never worked or were never
used, but no one was able/willing to go through the whole
application listing the necessary elements.

My two big projects for the last year were (are) exactly this kind
of project, i.e., an old one that's been in use for a long time and
where the original developer is gone, and that have lots of orphaned
items. Blessedly, the first of the two had not a single line of VBA
code in it, so no compile problems. But it had tons of macros, which
are actually much worse, since there's no reliable way to debug them
and figure out how they inter-relate with each other and with the
form/report objects -- I'd prefer a project that depended on
non-compilable VBA (as with my latest).

The fun non-compilable VBA in the current one is mostly from reports
that were created from forms that had record navigation on combo
boxes, so refer to the report's (formerly form's) RecordsetClone,
which doesn't exist, of course. And most of this navigation code is
attached to controls that don't exist any longer, anyway! Oh, well,
I get paid for the work either way.

 

[De Jager]

I need to convert a database to ACCDE and need to compile my VBA, however
when I select Compile under the Debug menu I get the following error,
"Method
or data member not found".

The problem is that the Sub it is identifing is a part of my database and
works well when I use the database.

The code that failed was the following with ".Combo2" highlighted in the
second line.

Private Sub Combo2_AfterUpdate()
TransferSection = Me.Combo2
MsgBox "Transfer Section is " & TransferSection
RunCommand acCmdRecordsGoToNew
RunCommand acCmdSelectRecord
RunCommand acCmdPaste
RunCommand acCmdSelectRecord
Me.[Inspection Section] = TransferSection
Me.Combo2.Visible = False
Me.Refresh
End Sub

Thanks for the help
Dan

 

[joelgeraldine]

rrtyujklllmm

This is the kind of thing that puzzles me. While it may not be your
database and you are just taking over responsibility for it,
somebody was responsible for creating a database that doesn't
compile.

This is malpractice, in my opinion. It may indicate incompetence.

Compiling is something an Access developer should do FREQUENTLY,
like EVERY FIVE MINUTES. I do it after every few lines of code. Why?
Because it catches my typos and insures that my app is always
compilable.

Here are some basic best practices for developing in Access:

1. in VBE options, turn off COMPILE ON DEMAND.

2. make sure you have OPTION EXPLICIT in all modules (this is a
setting in VBE options, i.e., REQUIRE VARIABLE DECLARATION should be
turned on).

3. in the VBE, add the compile button to your toolbar so it's very
easy to compile on the fly (I also add the CALL STACK button, too,
as it makes it easier to navigate in break mode).

4. periodically decompile/recompile to insure that no crud
accumulates in your VBA project.

5. in code, always specify parent objects. You can get away with not
doing it, but it's not a good idea. That is, in a form module's
code, you can use txtLastName to refer to a control, but it's better
to use Me!txtLastName (my preference) or Me.txtLastName. This makes
the code clearer and makes it more manageable in the long run, as
well as making it easier for the compiler (which may make mistakes
if you aren't explicit).

This is all so basic I am always surprised when people don't know
these things.