Tips on How to Document Report Design?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have developed what is (for me) a fairly complex report, with a number of
fields that are not visible, but are necessary to the report's functioning,
and some programming On Print and On Formatting. Depending on the data, the
report looks different.

I'll be moving on in June. They should replace me with someone trained in
Access, ideally much better trained than I am. However, there's a good
likelihood that that may take a year or two.

I'd like to leave behind something that explains how this report works, so
that someone trying to adjust it to changing realities in years to come can
do so, particularly if they are not so well skilled in Access that they can
do better rewriting it from scratch.

I've got comments in the programming, but has someone got some suggestions
about good ways to document what is going on in a report design?

Actually, any tips on how to leave records that explain what is happening in
a database as a whole would be helpful. An expert will be able to backtrack
it, but how do I tell some future novice what I did? Which kinds of things
are they likely to need to know? Probably too broad a question, but maybe
you have a pointer or two you could give me.

Thanks.
 
Just like you can use comments in your code, you can add invisible labels to
your report (or form). I have often created a hidden table with
documentation on tasks, status, dates, names,... You can build reports and
forms to help maintain the documentation table or tables. Try to keep your
documentation objects generic so that you can import them into other
applications.

There are tools like Visual Source Safe that can be used with Access to
track versions and store other documents.
 
Back
Top