UtterAccess HomeUtterAccess Wiki

Welcome Guest ( Log In | Register )

Custom Search
Edit Discussion
> Library Databases    
Library Databases

Libraries and Reference Chains (Forum Topic)
Exposing Classes in Library Files (Forum Topic)

Library Databases may be created and referenced from another database to aid in organizing code. This is especially useful for boilerplate code procedures that may be used throughout a number of projects. This allows us to maintain a working version and distribute the version among numerous applications. When we modify a particular procedure in the master copy, we need only to redistribute it, rather than go to each application, find the procedure, update it, etc. etc. Another useful tool of the library database may be for complex operations that you may wish to keep segregated from the main application, such as wizards and development tools.


Adding a Library (Reference)

With the Library Database, a reference must be created to the library from within the main application. From the Project References List in the VBE (VB Editor -> Tools -> References), click the "Browse" button to select the file that you wish to reference. Library files can be placed in the main applications root folder to ensure that it will be available regardless of the environment from which the application is run.

File Types


When adding an mdb or accdb file as a reference, little needs to be done after. When an updated version is available, it can be replaced with no further requirements (assuming that the updated version has the same filename as the previous version).


Executable database files are given a unique identifier when compiled. Upon referencing the library database that is an mde or accde file, the reference is linked through this unique ID. Therefore updates to the library file must be rereferenced from the main application. In other words, with an mdb/accdb file, we can copy and replace and be done, but with an mde/accde we unreference the existing libraries, copy and replace the libraries, open the main app and rereference.

While this is significantly more of a maintaince project, there is a definate added benefit of protected code and objects in the mde/accde versions.

The mde/accde file must be compiled with the same version of Access as the project which references it. In other words, if your Access version is 2003, the library mde must be compiled with Access 2003. As long as your library source file does not have code that is incompatible with one or other Access version, you can use the same VBA source for each compiltation. If you compile several versions, you can distinguising between them by using some indication of the version in the mde/accde name. For example, MyLib2K9 would inidicate that this is the Access 2000 version of the code library.

Objects In Library Databases

There are some caveats to using various MS Access objects in a library database. Here are the basics:

Tables and Queries

Tables and Queries exisiting in the library may not be called directly from main application. However, they may still be desired and utilized, such as may be the case when designing a wizard type library. To reference the table in a library database a link (TableDef for a linked table) must be created from the main application to the library application. This can be done during design or on the fly programmatically.

Tables and Queries that reside in the library database may be accessed through forms and reports also existing in the library database. For example, if LibDb1 has Form1 and Table1, we may reference Table1 from the main application inherently by calling Form1

Forms and Reports

Forms and Reports existing in the library database cannot be directly opened from the main application. However, they can be used by calling a public function in the library that in turn opens these objects for us.


Macros, such as forms and reports, cannot be called directly via the main application. Again, a public function or sub residing in the library that runs the macro must be called from the main application.


Standard Modules

Standard Modules in Library Databases can be accessed as usual. Public procedures and properties can be called, while private ones cannot.

Class Modules

Class modules cannot be directly referenced in a library database. However, a wrapper function or sub can be created in a standard module to instantiate the class on our behalf.

Tips on Library Creation

  • Name the project something other than the standard "AccessDb9". The Name of the library is used when the library is loaded into another database and may cause a conflict if left default.

Tips on Library Editing

  • Don't edit the library database through the main application which references it. Although it may be allowed (mdb/accdb), changes will not be saved and will usually result in a crash of the application. Always close the main application, open the library independently, make the edits, close the library, and reopen the main application.
  • Always attempt to maintain backwards compatibility when making edits to library databases. This is fairly easily accomplished by editing existing procedures to include new optional arguments and possibily making existing arguments optional where required.
Edit Discussion
Custom Search
Thank you for your support!
This page has been accessed 9,516 times.  This page was last modified 00:04, 6 October 2012 by Jack Leach. Contributions by Glenn Lloyd  Disclaimers