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 in Visio.
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 this pdf document Navigating Through Recursion, Part 1
