About the Series ...

This article is a member of the series MS Access for the Business Environment. The primary focus of this series is an examination of business uses for the MS Access relational database management system. For more information on the series, as well as the hardware / software requirements to prepare for the tutorials we will undertake, please see the first article of our series, Create a Calculated Field with the Expression Builder.

Note: The majority of the procedures I demonstrate in the series are undertaken within MS Office Access 2003, but are applicable to earlier versions of MS Access. However, the concepts that we explore in this article will apply to MS Office Access 2003 and beyond only, as the functionality we will explore is new in MS Office Access 2003.

Overview

In the last article of this series, MS Access as a Documentation Tool: Database Diagramming, we began an examination of the use of various MS Access features as documentation tools. We focused on meeting the important need of diagramming our databases for several reasons, including the support of a data dictionary as well as various enterprise reporting and other development efforts.

In this article, we will examine a feature that is new in MS Office Access 2003, and which offers great potential in our documentation, maintenance, and general upkeep efforts, from the perspective of the organizations MS Access databases. In MS Office Access 2003, we can directly and easily view information on dependencies between database objects. The capability to view a list of a database's objects, particularly within the context of how those objects relate to each other, can help us to maintain a database over time. The capability is perhaps most useful in helping us to avoid errors that emerge with the uninformed removal of record sources or other databases objects, but numerous other potential uses exist, as well.

Many of us are familiar with a scenario within which we have inherited a database environment that contains duplicate, non-working, or other objects of questionable utility. The reasons for the "object graveyard" are legion, but we can well understand that, for successful DBAs and developers, organization is certainly a virtue. The need to purge objects that are useless, or of unknown origin / vintage, is, in these cases, second only to the need to ascertain that they are, indeed, truly useless. To that end, the need to verify that dependencies do not exist between the valid objects and the suspect object(s) is critical.

We often need to generate a quick view of the dependencies among objects when we undertake such a housecleaning. With this, and other scenarios, in mind, Microsoft incorporated the capability to view object dependencies in MS Office Access 2003. In this article, we will explore using this capability for documentation and maintenance support purposes. We will:

• Discuss our objectives within the article, and present a scenario upon which we will base our practice example;
• Overview the View Object Dependencies capabilities in MS Office Access 2003;
• Discuss required preparation for using the functionality;
• Overview limitations and other considerations involved;
• Perform a hands-on exercise wherein we illustrate the use of the View Object Dependencies functionality in supporting client documentation functions.

[1] [2] [3] [4] [5] [6] Next