Christopher R. Weber
Knowing your way around your Access project is important for any developer. In this
first of two installments, Christopher Weber takes us through a navigation map
generating algorithm he uses to populate a table that describes how the forms and
reports in an Access database relate to each other. In next month’s issue, Chris will
demonstrate recursive query and reporting techniques he uses to generate a tree
navigation map of the database.
HAVE you ever taken over a large Access project and been overwhelmed
in the first requirements meeting by the plethora of synonyms used to
talk about a Client/Customer/Whatever entity? Then there’s the
corresponding jargon for the Client screen, the Customer form, or the
Whatever interface. And everyone in the meeting expects you to know how to
navigate through the product you’ve barely seen.
I’ve walked into this situation at least three times in the past year: once
taking over a project started by another developer, once consulting on a
project managed by another developer, and once being added to a team of
developers on a very large Access project. Invariably, the project is thrashing to
catch up to an arbitrary schedule, there’s little or no documentation, and the
work needs to be finished yesterday. It’s always the same problem (“the Client
screen needs to have such and such”) and I’m always asking the customer,
“Okay, show me how you got there.” At some point, I have to sit down and
map out all of the navigation routes possible in the project, either on paper or
Wouldn’t it be nice to have a form like the one in Figure 1 (on page 4) that
shows you all the links between interfaces (forms and reports) in the database?
Wouldn’t it be nice to have the data generated for you automatically?
Mapping your interfaces isn’t a trivial matter and really should be done in
the architectural stage of requirements gathering in order to limit the product’s ....
Read more on this topic in pdf form