Hi Jack
The easiest way to implement this is with a referenced MDE. It's very
simple - just create an MDB with nothing in it but modules containing your
code. Then 'compile' it into an MDE and set a reference in your other
projects to the MDE.
Class modules are a bit of a problem, because there is no 'easy' way in
Access to make a class module both Public and Creatable. However, there are
ways around that.
The one major drawback of an MDE is that the class GUID of an MDE changes
every time it is compiled. If your client frontend projects are also MDEs,
the class GUID of the library MDE on the end-user system must exactly match
that of the version that the frontend was compiled with.
This means that, say you add a new function or make an even more minor
change to your library on your development machine, and then recompile
frontend A (which is not affected by the change), then if you redeploy A.MDE
to another machine, you must also redeploy Library.MDE.
Perhaps this might not seem like a problem, but if the destination machine
also has frontends B and C which reference the library, they must be
recompiled and redeployed too, because otherwise they will refuse to work
against the new library.
This can create something of a maintenance nightmare. A workaround is to
deploy the frontends as MDBs (because an MDB will recompile against the new
library next time it is opened), but this is hardly satisfactory.
A much more satisfactory solution is a DLL, but it is much harder to
implement. The advantage is that you can set "Binary compatibility" on a
DLL, which means that all class GUIDs remain the same after a rebuild.
Essentially this removes the inbuilt compatibility protections and leaves in
your hands the responsibility to ensure upward compatibility. You can even
(carefully!) add new, optional arguments to existing methods in your library
without breaking the compatibility.
The disadvantages are:
1. You need VB6 or Visual Studio .NET to create a DLL. Involves expense and
a learning curve.
2. There is no access ('scuse the pun) to the nice, built-in objects such as
Application, DBEngine, CurrentDb, CurrentProject, etc. The workaround to
this is to declare them as properties in your DLL and initialise them at
application startup - for example:
Set MyLibrary.AccessApp = Application
3. If your library uses tables (e.g. error codes for global error handling)
they must be deployed in a separate MDB file. Not really a problem, except
for maintenance.
4. If your library uses forms (e.g. for a general-purpose calendar) then
they must be VB6/.NET forms - usually not a problem, except for the learning
curve.
Hope this is of some help!
--
Good Luck :-)
Graham Mandeno [Access MVP]
Auckland, New Zealand
"Jack Leach" <dymondjack at hot mail dot com> wrote in message
news:0994F58D-0AEE-40C5-89DF-(E-Mail Removed)...
> I've been trying to find information on this but have been drawing blanks,
> hoping maybe someone can point me in the right direction.
>
> I want to make an external reference library that I can access within my
> project, but not sure how to go about doing it. I'm working on a basic
> CAM
> programming interface to integrate, which invloves a ton of various math
> forumlas.
>
> I'd like to get these formulas into their own library, which I can
> apparently do by referencing a seperate mdb/mde. But I think I'd rather
> not
> have an mdb for this... I don't need any interface or data, just
> functions,
> so an mde is a bit overkill I think.
>
> I assume a dll is ideal for this, but I haven't the faintest idea how to
> work with them or what the learning curve is (if I understand correctly
> vba
> cannot create dlls anyway).
>
> Any ideas or pointers to places where I can find good information on the
> concept?
>
> Thanks,
>
>
> --
> Jack Leach
> www.tristatemachine.com
>
> "I haven't failed, I've found ten thousand ways that don't work."
> -Thomas Edison (1847-1931)
>
Similar Threads
