Within 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.

The expanded tables appear as depicted in Illustration 10.

The 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).

The 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.

Using the 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.

We return to the view of the objects that are dependent upon the Products table.

At the bottom of the Dependencies pane, as partially depicted in Illustration 13, we notice that the following phrase appears:

Warning:  Some objects were ignored

In addition, a folder titled Ignored Objects appears in the tree in the Dependency pane, just above the Warning message, as depicted in Illustration 12.

As we 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.

Moreover, 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.

We can see a ready example of objects that are ignored due to the former reason, lack of support, by taking the next step.

The 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).

Ignored Objects are 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.

Conclusion...

In this 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.

We 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 memorable way.

» See All Articles by Columnist William E. Pearson, III

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