Hello all,

I've run into quite a funny problem that seems to be reproducible, and I was
wondering if any of you had any experience with this, to provide either a
workaround, or to confirm that this is in fact a problem with Access.

I have a main MDE that references another library MDE.  They both work great
... that is, until I change some code and recompile the library MDE.  Once I
do that, when I run any code in the main MDE, I get the error message:

Compile error:
Requested type library or wizard is not a VBA project.

I know this isn't something that I'm doing with my code, because if I run
the uncompiled main MDA file, which also references the library MDE, it
works fine.  Furthermore, if I take the main MDA file, make no changes, but
just recompile it into a new main MDE, then the new main MDE will work.

Therefore, it seems as if the simple action of changing the library MDA and
then recompiling it into a library MDE causes the referencing main MDE to
fail, unless recompiled.

I have searched the newsgroups as well as knowledge base, and I find an
article which is similar (Q248895: ACC2000: An MDE File That References
Another MDE File Cannot Run Code After Both Are Moved to Another Folder) ,
except that I have NOT moved the files to a different location -- they are
both in the same directory as originally.

Is this something that anyone is familiar with?

Charles

Very similar to  installing new version of a referenced DLL or OCX on
your system without remaking the main MDE.

Tony

----
Tony Toews, Microsoft Access MVP
   Please respond only in the newsgroups so that others can
read the entire thread of messages.
   Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

Really?  Is that true, about installing a new OCX?  It's important because
we actually do have some OCXs too that we deliver with our application ... I
mean ... I would think that as long as the new DLL/OCX is
"backwards-compatible" (still exposes the same methods/properties, with the
same results), installing a new version of the DLL, as long as it's the same
file name, should work on an old MDE that was compiled on a computer that
had the old version .... it won't?

If so, I'm going to have to rethink some of our distribution plans :(

Charles

In my case, the front-end is compiled to an MDE with a reference
to
another compiled "library" MDE that has re-usable code.  If I
later
update the library MDE only, it breaks the front-end MDE. I must
first re-compile the front-end with a reference to the new
library MDE.
Both new front-end and library MDEs must be installed together,
along with a RefLibPath entry in the registry in case the user
installs
to a different path.

The bad side effect of this is that if you have multiple
front-end compiled applications that use the same shared library
on a single computer, you must rename each  compiled library
uniquely for each front end.  Otherwise, when you update a
library for one application, you not only must update its
front-end, but you also need to update EVERY front-end that uses
the same RefLibPath!  This is because the RefLibPath entry is
keyed on the name of the library file (bad design).  So you must
keep a different compiled library file name for each front-end or
be willing to update all front-ends at the same time.

For example, as a developer I may have A.Mdb and B.Mdb as
front-ends referencing L.Mdb. For installs, I compile L.Mdb and
rename it to A.Lib, then compile A.Mdb to A.Mde with a reference
to A.Lib, and setup the RefLibPath to A.Lib. Similarly B.Mde is
compiled referencing B.Lib. Painful, but it can be fully
automated using automation, and the applications can be updated
on the same computer independently.

Now if your front-end is an un-compiled MDB, then you can easily
replace a compiled reference library MDE with no problems.

- Steve

TIA

Frank

The sample code is copied from working code, but overly-specific
stuff has been removed, such as names of files and my version of
error handling.  Note this code is run from a separate developer
database that is neither the front-end database nor the library
database.

1) Convert the library .Mdb source to a compiled library .Mde
using:

SysCmd 603, strLibraryMdbFile, strLibraryMdeFile

2) With the front-end source .Mdb, switch its reference to the
new compiled library .Mde.

Dim appAccess As Access.Application, ref As Reference
Set appAccess = CreateObject("Access.Application")
apiSetForegroundWindow appAccess.hWndAccessApp
apiShowWindow appAccess.hWndAccessApp, SW_NORMAL
'the first call to ShowWindow doesn't seem to work??
apiShowWindow appAccess.hWndAccessApp, SW_NORMAL
appAccess.OpenCurrentDatabase strDbName, True
' remove the prior reference to source library .Mdb
' actually I scan to match the ref.FullPath, but the next line is
simpler
Set ref = appAccess.References(strLibraryProjectName)
appAccess.References.Remove ref
Set ref = Nothing
'add new reference to the compiled library .Mde
appAccess.References.AddFromFile strLibraryMdeFile
DoEvents
appAccess.SysCmd 504, 16483 ' Compile All
appAccess.Quit
Set appAccess = Nothing

3) Convert the front-end .Mdb source to a compiled .Mde using:

SysCmd 603, strFrontEndMdbFile, strFrontEndMdeFile

4) Put the front-end source .Mdb reference back to the source
library .Mdb. This is the same as Step 2), but reverse the
references, or better yet make a function and called it reversed.

When you are done, you have your original front-end .Mdb
referencing a library .Mdb file the way it started out (for later
development), plus you have a new compiled front-end .Mde
referencing a new compiled library .Mde file ready for
distribution.

- Steve

I know I'm asking a lot of questions again: this is because about a month
ago I started using a 'system database' within 10 applications that I've
develloped. The primary goal of this was timesaving aspects: It would be
much easier to only have to make alterations at one specific spot instead of
10 different spots. But because of the problems discussed here and because
of the fact that I was unable to solve this fast enough I decided to switch
back to local handling instead of referenced handling.

I'm eager to know what your thoughts are on this.

TIA
Frank

By the way, the API calls and undocumented SysCmd calls come from
Dev's great site at http://www.mvps.org/access/.

I do not load the database as an add-in library in Access 97, I
simply reference it under Tools References.

Any file name can be used for any Access database, including a
referenced database, with any extension whatsoever. It does not
need to be .Mda or .Mde or .Mdb.  For example, I use a .Lib
extension for the compiled referenced library. It does make
things a little more awkward to open the database in Access if it
does not have a standard extension, but not a big deal.

- Steve

Frank

PS: I've become quit farmiliar with Dev's site in the mean time!\