either view of dependency, we can take advantage of the expanded details we
noted above. In addition, we can "drill" to the granular specifics
of the dependencies in many cases (up to four levels deep, where applicable),
as we shall see in our next step.
Expand the Order
Details table, listed in the Tables section in the Dependencies
pane, by clicking the "+" sign to its left.
Expand the Orders
table, appearing underneath the newly expanded Order Details table, by
clicking the "+" sign to its left.
tables appear as depicted in Illustration 10.
Illustration 10: Expanding
a Couple of Levels in the Object Dependencies Pane
Click the Table:
Products entry beneath the Order Details table, to select it.
table appears, in Design view, to the left of the pane, as shown in Illustration
11 (just as it would if selected from the Database window).
Illustration 11: The
Dependent Table Appears, Providing More Details for Documentation
view indicates the field in the table that underlies the respective dependency
listing, providing yet another level of detail for our documentation of the
object dependencies within the database.
Objects that depend on me and the Objects that I depend on
selections within the Dependencies pane, we are able to make a note, in
our objects inventory list, of the dependencies surrounding the Products
table. Furthermore, we can easily identify objects with no dependencies as "candidates
for extinction" before upgrading the database to MSSQL Server; the
responsible client team will decide the appropriate course of action based upon
the input that we are thus able to provide.
Select the Objects
that depend on me option, by clicking the radio button to its left,
atop the Object Dependencies
We return to the view of the
objects that are dependent upon the Products table.
bottom of the Dependencies pane, as partially depicted in Illustration
13, we notice that the following phrase appears:
Warning: Some objects were ignored
addition, a folder titled Ignored Objects appears in the tree in the Dependency
pane, just above the Warning message, as depicted in Illustration 12.
Illustration 12: Returning to the
Objects That Depend on Me View Option
intimated earlier, MS Office Access 2003 ignores objects for a couple of reasons. First, if the
objects under consideration are outside the scope of supported items,
such as SQL-specific queries (and other objects we discussed above); MS
Access will exclude them from the Dependency view. These objects do not
support Name Autocorrect, as we saw earlier, and therefore do not update
the name map that underlies our capability to view object dependencies.
we mentioned earlier that a user attempting to view object dependencies needs
to have permission to open the object under consideration in Design
view. The reason for this is that MS Office Access 2003 must be able to open,
close and save a given object in order to generate dependency information
surrounding that object.
see a ready example of objects that are ignored due to the former reason, lack
of support, by taking the next step.
Expand the Ignored
Objects folder, which appears just above the Warning message, by
clicking the "+" sign to its left.
Expand the Unsupported
Objects folder that appears next, just below the Ignored Objects
folder expands, and we see a couple of unsupported objects listed, as shown in Illustration
13 (just as it would if selected from the Database window).
Illustration 13: Example
Unsupported Objects, Appearing in the Ignored Objects Folder
grouped, by reason for their classification as "ignored." The
Ignored Objects folder above contains only ignored objects of the unsupported
class, as we have universal permissions in the sample database.
Close the Northwind
database when ready.
Exit MS Access
article, we discussed another feature, new in MS Office Access 2003, which
assists us in supporting database documentation. We established a scenario
within which we are engaged to assist a client in meeting a hypothetical business
need to document the dependencies of the objects in a database. The database
has been inherited, without documentation, from departed designers within the
organization, and management now seeks to know more about the objects within
the database. We discussed illustrative uses for object dependency information,
both within the scope of our example scenario and in general, and then
introduced the View Object Dependencies capability that MS Office Access
2003 makes available.
discussed required settings that must be enacted for the View Object
Dependencies functionality to be available, commenting on the reasons that
the settings are mandated as they are. We then used the features within the View
Object Dependencies functionality, examining navigation, options, and
limitations in a manner to activate the concepts we had discussed in a
See All Articles by Columnist William E. Pearson, III