Compile Errors from 02 when opening an 00 MDB

[Rob]

When I open my Access 00 MDB in 02 on my clients'
machines, I get a compile error. They run Office XP under
WinXP. Thinking that it may be a library problem, I
opened the References window under the Tools pull-down
under Access 02 - which the compiler let me do even though
I couldn't make changes to the code (I don't think).
The "utility" library was marked "missing". The bad thing
was that there no references to the code that was calling
it. The directory location was pointing to
the "C:\Program Files\Microsoft Office\Office10
\utility.mda" location, and I could find the file using
Windows Explorer.

I have a copy of OfficeXP running under Win2k. There,
the symptoms are different. I get a "couldn't execute"
macro" message. In both cases, I seem to be able to
continue on. The code that causes these errors is calling
Word for a mail merge. The merge document gets created
anyway, and it does the merge successfully.

One thing I noticed this AM as I'm writing this is that,
after executing the MDB on my copy of OfficeXP under
Win2k, when I tried to open the same MDB on my copy of
Office 2k under Win2k, it now tells me I am missing my MS
Word 10.0 Object Library. Don't have time to redirect the
reference to the Word 9.0 library now, but that is what I
will try next.

Two questions:

1. How can I pinpoint the offender in Acc 02? (and/or fix
it if the solution comes to your mind?)

2. How (if possible) can I prevent Acc 02 from corrupting
my library references?

TIA,

Rob

 

[Peter Russell]

2. How (if possible) can I prevent Acc 02 from corrupting
my library references?

You can't.(And they are not being corrupted, they are being retained!)
Any non-native libraries keep their references. This includes
references to any other Office programs.

You can avoid using such references by causing the technique called 'late
binding'. In this approach you do not add references;you assign the
relevant objects to non-specific object variables.

(The technique of adding libraries to references and using the native
library objects is referred to as 'early binding'.)

There is some info in Online Help about this and it is superficially
straightforward. The two problems when you use it for the first time is
that you have to decode all the built in constants to their numeric values
as the application will not have the library there to decode the constants
for you and there is no Intellisense for the non-native objects. But this
does get over the references problem.

Some developers use an approach of 'develop early- deliver late'
In other words, they do the main development with library references in
place so that they get all the Intellisense benefits and then convert to
late binding immediately prior to delivery so that the app is not
dependent on specific libraries.

Regards

Peter Russell

 

[Rob]

Peter,

Thanks. It helps to have some understanding of what is
going on. While I am not wild about the work of late
binding, I appreciate the insight.

I was able to eliminate the compile errors under Access
02. The database is not split; so, part of the solution
was to rename the AutoExec macro that put the user into a
menu. It executed when MS Word initiated a second
instance of the DB. The problem is one a vaguely alluded
to yesterday:

I tried to call the renamed macro with the /x parameter in
the command line which launched the MDB for the user.
With that call, the same macro that worked when it was
named "AutoExec" resulted in an "Action Failed" error.

My ultimate solution probably will be to split the MDB.
However, lazy me would like to know if there is an
explanation and a solution for the macro's failing. It is
aggravating to have the same doggone macro fail just
because it is a different name. I thought the /x
parameter simply caused a macro of a different name to be
called just like the AutoExec macro.

TIA,

Rob

 

[Peter Russell]

if there is an
explanation and a solution for the macro's failing. It is
aggravating to have the same doggone macro fail just
because it is a different name.

I thought the /x
parameter simply caused a macro of a different name to be
called just like the AutoExec macro.

Me too.

I don't think I have ever done this, and the only issue I can come up with
without testing is that I assume that the macro name must be in quotes,
since all other object references in the command line have be so enclosed.

If this is not the problem then continue by posting your shortcut to see
if anyone has any ideas.

Regards

Peter Russell